Can a flash front end talk to a .net backend?
Yes.
We use Adobe Flex to talk to .Net XML web services.
Be careful with complex serialised .Net types (for instance DataSets) - ActionScript can't handle them.
Instead produce simple XML with primitive types.
See also: Flex and ADO.NET Data Services...anyone done it?
<mx:WebService id="myDataService" showBusyCursor="true">
<mx:operation name="WebMethodName" resultFormat="object" result="functionFiredOnComplete();"></mx:operation>
</mx:WebService>
public function load():void
{
myDataService.loadWSDL( "web method's wsdl" );
myDataService.WebMethodName.send( params );
}
public function functionFiredOnComplete():void
{
// get data
var myData:Object = myDataService.WebMethodName.lastResult;
...
Flash can also talk to the hosting page via JavaScript.
you could also try AMF.NET, a .NET implementation of Flash Remoting using ActionScript Messaging Format (AMF)
http://amfnet.openmymind.net/overview/default.aspx
Yes
Best keywords to search for are Flash .net and Flex
In the old days there was another tool but with Flex its all been simplified.
If you are de/serializing a lot of objects (which Flash/Flex isn't particularly fast at), or more complex types, then you might want to take a look at WebOrb. It's a free object broker, which might sound scary, but it basically handles translation between the native object types of the two technologies. It pretty much "just works", and can increase performance quite significantly in some situations.
It also comes with a code generation tool if all you want is CRUD and stored procedure access for a SQL database, which is quite nice.
I would recomend FluorineFX we use that at work and its great. The only downside is that we end up with a lot of value objects that are only used to transfer data between .net and flex. And the fact that the standard C# naming style and the flex naming style has some minor differences makes value objects a bit ugly in either flex or .net.
My older brother and I developed several methods for Flash/.Net communication. I've seen web services mentioned above (which is a great way of doing it), but we also used simple .aspx pages and had stuff passed via querystring (poor man's way of doing things), using Flashvars to get data TO Flash, but my favorite - Using .Net and a repeater control to build xml files which were then consumed by Flash. We created some pretty cool stuff doing that!
Related
I'm conducting a project in which a website should have multi-language support.
Now, this website is supposed to serve about 500K+ visitors a day, so it must be super-efficient.
I've created a table of parameters {[ID],[Name]} AND a linkage-table {[objectID],[parameterID],[languageID],[value]}. I think it's the best way to deploy multi-language support while having the privilege to translate different parameters for each language.
As far as I know, server's memory is much faster than a physical HDD. Therefore, I'm planning to store ASP.NET Application State objects for my translation architecture.
(http://msdn.microsoft.com/en-us/library/ms178594.aspx)
How does my plan sound so far? any suggestions?
If you are planning on making an app that support multiple languages, your instant reflex should be let .net do the work for you. What i'm reading in your question is that you are setting up something to support that. You should know that localization is the way to go when you want to develop a multi-language environment.
Take a look at this msdn article, it should give you a general idea on the topic.
So, localizing an application can be divided into two parts:
Localizing business logic entities.
Localizing everything else.
In the question I see words which are related to business entity localization. For that purpose I agree with the concept to have separation between entities and their localizations.
Part 1 - Localizing entities:
Personally I do this way in database:
table Entity {EntityID, Name} -this is the entity-related table.
table EntityByLang {EntityID, LanguageID, Name} -this is the localized version of the table for each supported language.
This way allows me to have default values for each localizable property like Name and its localization, if such is available in the localized table. What's left here up to you is - you need to implement the data-access-layer which takes the Name localized for the current user language, or the default value (if language or the translation is not available for the given language).
Part 2 - Localizing everything else:
Here, with no alternatives in terms of the performance, I would recommend using some kind of static resources. Personally I live with static resources available for standard asp.net applications.
From the architectural point of view, don't directly refer to localization code from your UI code, like this (which I don't like):
var translation = HttpContext.Current.GetGlobalResourceObject("hello");
//excuse me, if I don't exactly remember the GetGlobalResourceObject() method name...
Instead, I would recommend using this kind of approach:
var translation = AppContext.GetLocalizationService().Translate("hello");
Where: AppContext - some kind of facade/factory (in fact, implementation of abstract facade/factory). GetLocalizationService - initially returns some kind of ILocalizationService, when implemented it returns StaticResLocalizationService (which implements ILocalizationService). This way allowing switching from one kind of localization to another. And particularly StaticResLocalizationService works with asp.net static resources
Sorry for messy sample codes, but I hope you understand my approach.
I hope this helps!
I would suggest to create custom resource provider, you can read more here:
http://msdn.microsoft.com/en-us/library/aa905797.aspx
with this model you can leverage existing asp .net localization functionality
I just started working on an asp.net / C#.net application that is going to call a number of different procedures. The -only- thing these procedures do is create database table views, and the only thing I want to do is to store the information in variables. Then pick out which columns I want to convert to JSON, and then make a JSON string. I've actually written code for that in C#.net already, which is smaller, but since I switched to asp.net mvc I'm a little unsure if I should keep it or go with the whole Linq thing.
I checked out the Linq --> SQL drag & drop functionality, and that instantly created about 200 lines of code with set & get methods and everything.
So my question is, is it still worth using Linq even for just extracting data? Eventually this data will be fed to a javascript timeline, which is where I was told MVC would be highly useful with regards to Ajax functionality.
Since you are only using LINQ-to-SQL for data retrieval, I can't think of a single reason NOT to fully utilize it. I've been working on an MVC 1.0 project since last April. During that time, I've had to quickly become familiar with a number of technologies, LINQ-to-SQL being one of them. Get comfortable with it, and also look at the repository pattern...you will be very content and things will go relatively smoothly.
Now, when you get to INSERTs and UPDATEs, things are going to get a little more sticky. LINQ-to-SQL is still up to the job, but you'll need to understand how things work internally a little better. I highly recommend "Pro LINQ (Language Integrated Query) in C# 2008" by Joseph C. Rattz, Jr. The sections covering LINQ-to-SQL easily take up over a third of the book with detailed examples.
As far as the JSON objects go, LINQ-to-SQL's biggest contribution is that it allowed me not to have to worry about creating specialized views or stored procedures just to handle those one-off-types of data retrievals. My current project has a database of 65 tables...NO stored procedures. I can do filters, unions, multi-level joins...and it's all maintained in the application. Sweet...
Yes, it's totally worth it!
LINQ2SQL provides you a great subsurface to retrieve and save data to.
However, you'll need to implement your own Repository Pattern as you dig deeper into ASP.NET MVC.
And during the implementation of the Repository and the required (and even custom / webapp-state based) Queries, you'll be very glad to have all the power available at your fingertips that LINQ provides.
LINQ only adds to the available toolkit you can lean on when creating code. Even if you are using LINQ in a trivial way now, implement it, get familiar with it, and take advantage of the power it gives you both on this project and future projects.
Linq2Sql is quiet good for creating select queries. As it is appearing that you need to create JSON objects from database views it will be quiet useful
I'm implementing some objects which will have about an equal amount of richness on both the client-side and server side.
In this particular case, I'll be building a (hopefully) little class library to deal with search tokens. So as a pseudo-code example, I'll want to be able to do the equivalent of the following in both Javascript and on the server (C# in my case).
s = new SearchTokenList();
s.Add(new SearchToken(field, value, negation));
What design strategies will help avoid creating a big ball of mud for a library which must span C# and Javascript?
Update: Looking for more of strategies than mechanics. But I'll take any guidance I can get from those who have previously done similar things.
Take a look at Script# by Nikhil Kothari, might help you out. It is a C# to JavaScript compiler.
I think you should check out my C# to JavaScript compiler out at http://jsc.sourceforge.net/
Unlike Script# my jsc compiler works on MSIL level.
WPF Example: AvalonExampleGallery
Contact me if you have any specific questions.
If performance is not critical, you could load the data in JSON or XML and pass it back to server-side and do the processing. I think WCF can generate JavaScript interface out of the box. See .NET by Example: Calling a WCF service from Javascript.
You should be able to run some Javascript code on your .NET server using Microsoft's JScript.NET -- compile it with /target:library and make sure it's CLS-compliant and that you declare that fact with
[assembly:System.CLSCompliant(true)]
or other variants of CLS compliance declarations. Once you've gotten this to work, you could run (a bit of) JS code on both the server (calling it from C#) and the client (calling it from other JS) and more easily ensure equal functionality on both sides.
Can I get some constructive feedback about the following architecture?
Simplified Architecture Summary:
Return XML from your SQL Server (using FOR XML) and pass it straight into a XSL transform to produce a rich HTML web site.
What are the pro’s and con’s of such a system when compared with a conventional 3-tier ASP.NET architecture?
We have done something like this. And it works for very simple pages. But as soon as you would like to include some client side javascript and similar, you are doomed.
The generated output is hidden in the XSLT stylesheets and it is very hard to read, maintain and fix bugs.
Testing can be done, but also with much more effort than before.
The MVC pattern and similar is much better suited for such a scenario.
Two cons.
Data manipulation with C# or VB.net becomes harder because you don't have classes with properties (code intellisense) but xml-documents.
There are built in asp.net controls for data entry validation (both client side and server side). You can't use them if you use XSLT to produce your HTML-page.
I've done something similar in a project. I find the architecture very clean and scalable, but I would only advise you to use it if you happen to have lots of XSLT expertise in house.
We have a few XSLT templates, and a generic c# class that performs the transformation, using XSLT parameters. We get very good performance but, for new developers, the app can be hard to maintain.
One pro:
You can make XSLT-templates that produces HTML for the browser or XAML for WPF/Silverlight.
I am VERY new to ASP.NET. I come from a VB6 / ASP (classic) / SQL Server 2000 background. I am reading a lot about Visual Studio 2008 (have installed it and am poking around). I have read about "reflection" and would like someone to explain, as best as you can to an older developer of the technologies I've written above, what exactly Reflection is and why I would use it... I am having trouble getting my head around that. Thanks!
Reflection is how you can explore the internals of different Types, without normally having access (ie. private, protected, etc members).
It's also used to dynamically load DLL's and get access to types and methods defined in them without statically compiling them into your project.
In a nutshell: Reflection is your toolkit for peeking under the hood of a piece of code.
As to why you would use it, it's generally only used in complex situations, or code analysis. The other common use is for loading precompiled plugins into your project.
Reflection lets you programmatically load an assembly, get a list of all the types in an assembly, get a list of all the properties and methods in these types, etc.
As an example:
myobject.GetType().GetProperty("MyProperty").SetValue(myobject, "wicked!", null)
It allows the internals of an object to be reflected to the outside world (code that is using said objects).
A practical use in statically typed languages like C# (and Java) is to allow invocation of methods/members at runtime via a string (eg the name of the method - perhaps you don't know the name of the method you will use at compile time).
In the context of dynamic languages I haven't heard the term as much (as generally you don't worry about the above), other then perhaps to iterate through a list of methods/members etc...
Reflection is .Net's means to manipulate or extract information of an assembly, class or method at run time. For example, you can create a class at runtime, including it's methods. As stated by monoxide, reflection is used to dynamically load assembly as plugins, or in advance cases, it is used to create .Net compiler targeting .Net, like IronPython.
Updated: You may refer to the topic on metaprogramming and its related topics for more details.
When you build any assembly in .NET (ASP.NET, Windows Forms, Command line, class library etc), a number of meta-data "definition tables" are also created within the assembly storing information about methods, fields and types corresponding to the types, fields and methods you wrote in your code.
The classes in System.Reflection namespace in .NET allow you to enumerate and interate over these tables, providing an "object model" for you to query and access items in these tables.
One common use of Reflection is providing extensibility (plug-ins) to your application. For example, Reflection allows you to load an assembly dynamically from a file path, query its types for a specific useful type (such as an Interface your application can call) and then actually invoke a method on this external assembly.
Custom Attributes also go hand in hand with reflection. For example the NUnit unit testing framework allows you to indicate a testing class and test methods by adding [Test] {TestFixture] attributes to your own code.
However then the NUnit test runner must use Reflection to load your assembly, search for all occurrences of methods that have the test attribute and then actually call your test.
This is simplifying it a lot, however it gives you a good practical example of where Reflection is essential.
Reflection certainly is powerful, however be ware that it allows you to completely disregard the fundamental concept of access modifiers (encapsulation) in object oriented programming.
For example you can easily use it to retrieve a list of Private methods in a class and actually call them. For this reason you need to think carefully about how and where you use it to avoid bypassing encapsulation and very tightly coupling (bad) code.
Reflection is the process of inspecting the metadata of an application. In other words,When reading attributes, you’ve already looked at some of the functionality that reflection
offers. Reflection enables an application to collect information about itself and act on this in-
formation. Reflection is slower than normally executing static code. It can, however, give you
a flexibility that static code can’t provide