With the arrival of .NET 3.5, WPF and the RTM of Silverlight 2, .NET developers have more choices than ever for designing, developing and deploying compelling applications with rich user interfaces. However, there are other mainstream alternatives that don't fall into the .NET camp. When it comes to the RIA world, technologies such as Adobe Flex and Flash may seem more foreign to some of us then driving on the left side of the road would be to an American. However, given the need to work on a Flex project, we are actually quite well suited for the transition, more so in many cases than developers coming from a more traditional web development world.

First off all, why choose to use Flex anyway? If you are building an RIA to deploy through the browser, Silverlight would seem the logical choice for a truly custom and unique UI when ASP.NET and AJAX don't fit the bill. But there are certain situations where an enterprise may decide that going the Adobe route is the correct choice for the needs of a particular project. The primary motivation comes with an application that is being built for external consumers. The Flash plug-in currently has a 99% market penetration according to Adobe and that's hard to argue with. This will be changing as Silverlight continues to be adopted but it currently remains an important consideration. As an example, I was recently involved in building an RIA meant to be subscribed to by many large financial institutions. These types of clients do not typically have the freedom to install browser plug-ins at will. Something like the Silverlight plug-in would need to be deployed in a firm-wide rollout after many months of compatibility testing, while Flash has been standard for years. Aside from this reason, the Adobe AIR runtime makes for a compelling usage scenario where your application assets can be deployed both in the browser or standalone on the desktop, allowing reuse of the majority of the same code base. AIR has a sophisticated web-based deployment and versioning model as well. Some form of this is expected in Silverlight 3 but it is already a reality for AIR. Finally, if you have a set of graphical assets already designed for Flash and designers who are most experienced in this area, the Flash/Flex path may be the easiest way to get the user experience you are after.

If you (or your project manager/architect) have decided that it must be Flex, don't be discouraged. While learning any new platform is a non-trivial undertaking, Flex is not as foreign to .NET as it may seem. When I've conducted interviews for Flex positions, usually the candidate came from a history of Java web development. The Flex platform enjoys close ties with the Java community, from its Eclipse-based IDE, Java style package naming, and Adobe's support of its Livecycle Data Services and BlazeDS APIs for remote service integration. However, I believe that the learning curve is more natural coming from WPF or Silverlight than from Java, culture and IDE differences aside. Rich Internet Applications are closer architecturally to desktop applications written in C++, WinForms or WPF than the standard non-AJAX web application. The kinship between Silverlight and Flash is even closer. RIAs are persistent applications that maintain state, and call remote services to load and store data (usually through XML or JSON), rather than loading pages of HTML. As such, the patterns for architecting one should follow those of a desktop application deployed in an n-tier environment. Further, the major elements of the Flex platform will be quite familiar to any WPF or Silverlight developer. Flex contains an XAML-like markup language for UI layout, an OO language to glue everything together, a mature set of controls and layout panels, an analogous eventing system, databinding, and a DataTemplate like mechanism.

Introducing the Flex 3 Framework
Flex is the UI toolkit for building RIAs based on the ActionScript language and running in Flash player, as WPF and Silverlight are frameworks for building applications in C# that run in the .NET CLR or Silverlight runtime. As WPF has XAML, Flex has its own analogous language called MXML that serves the same purpose. It is a serialization language for describing your application views by constructing trees of layout elements and control elements, and setting properties on them. Your MXML files get compiled to ActionScript and the MXML tags that you declare create instances of AS classes. Flex does not have the same concept of codebehind as you'll find in the .NET world, but ActionScript can co-exist in the same file as your MXML markup in a special CDATA block for this purpose. This ActionScript is just another part of the class that the MXML in the file gets compiled into, so the overall effect is the same.

Many other WPF constructs have similar analogues in the Flex world. Flex provides an eventing model that anyone familiar with C# delegates and events will have no trouble understanding. Routed events have been a part of Flex for as long as they were in WPF. These events have a tunneling phase (called "capture") where they travel down through the control tree from the top level (called the Stage in Flash) to the target where the event occurred, followed by a bubbling phase where they travel up the tree, in both directions, looking for any registered event handlers.

Flex has a databinding mechanism for connecting UI controls to model data. The syntax is more awkward than you may be used to, but you can (and should) still make use of this for binding your view controls to their model (or viewmodel). Unfortunately there is no concept of a DataContext, so even if a single model object provides all of the underlying data for your view, you'll need to specify that in each binding expression path.

For giving a custom look to lists of data as well as DataGrid columns, Flex gives you a construct called an item renderer that is quite similar to our familiar DataTemplate. An item renderer is usually a small tree of MXML, but can be implemented as a class with some behavior behind it. When binding to a list of data, Flex uses the renderer as a factory to create additional instances of the same class, used to render each underlying model item in the list. Just as in XAML, your item renderers can be declared inline, separated out into separate component files or even built up in code. Item renderers in Flex only apply to list data. With the PresentationModel patterns being applied in .NET 3.5 now, views are often being abstracted into a simple ContentControl rendering dynamically based on the DataTemplate for the bound Content, but you won't be able to do anything quite that clever here.

ActionScript
Learning the ActionScript language will present no major hurdle for anyone experienced with C# or Java. ActionScript 3 (the current version) is based on ECMAScript 4.0, and is largely grounded in OO principles with the addition of some ideas from the functional world. It is a true object-oriented language supporting inheritance, polymorphism and interfaces. The language is somewhat more dynamic; however, there are no strongly typed arrays or lists and you can forget about generics. There are no explicit delegates or events (objects fire events by implementing the IEventDispatcher interface). But functions are first class objects that can be passed as method arguments, used most frequently for adding handlers for events. Functions can also be anonymously declared inline. Interestingly, the ActionScript Array class has a number of higher order functions such as forEach(), filter(), map(), and some() for applying a function over a list of elements. If you are already using LINQ extension methods and delegates, you'll have no problem figuring out what to do with these. The language does leave out a few of the common OO constructs that you've grown accustomed to, such as abstract classes, private constructors and static initializers. While you will miss them, they won't be anything that you can't work around.

Flex makes use of the Flash player threading model in which all of the code you write executes on the single UI thread, so forget about doing CPU-intensive processing while keeping your UI responsive. You can perform some I/O bound operations through a model similar to .NET's Asynchronous Programming Model though. Through this mechanism, you schedule an asynchronous action to be executed by the Flash player, such as calling a remote service or reading a file. You provide an event handling function to be invoked when the operation is finished so you can process the results, but this will be invoked on the same UI thread. While this model can be limiting, it does free you from worrying about thread synchronization or the need to marshal data between threads.

Tool Support
Perhaps the most initially disconcerting part of your switch to Flex will be getting used to a new development environment. The FlexBuilder IDE is based on Eclipse, coming either as a standalone install + the Eclipse shell or as a plug-in for existing Eclipse installations. Eclipse is a full-featured IDE when using it for Java development, and you get out of the box a similar feature set to what you have with Visual Studio + Resharper. But FlexBuilder does not support most of the more advanced refactorings, code organization, and generation tools that Eclipse users might be accustomed to. Therefore, you may feel that you are taking a step backwards when making the switch from Visual Studio. Most of your basic debugging tools are present (there are no conditional breakpoints but this is coming in Flex 4).

The story is more fragmented regarding the UI designer/developer workflow. Expression Blend has come a long way toward allowing designers and developers to simultaneously work on the same source tree and have a productive working relationship. Unfortunately there is no equivalent in the Flex world, and no tool that generates MXML, which can build and run the same projects used in Flex Builder. There is a built-in WYSIWYG editor in Flex Builder, but like the XAML designer in Visual Studio, it's not very useful beyond trivial applications. In general the flow between developers and designers is not as natural. Achieving more interesting effects, skins, and animations in Flex is often a combination of handwritten MXML combined with artifacts generated from tools such as Flash IDE, Adobe Illustrator, and open source libraries like Degrafa.

The Server Tier
As mentioned, the Adobe Flex community enjoys close ties with the Java world, and you'll find that a majority of Flex applications are served from and call remote services on a Java application server, or servlet engine. A large reason is that Adobe has released and supported a suite of APIs for integrating Flash Remoting with Java, through its AMF (Action Message Format) binary protocol. These products, BlazeDS and LiveCycle Data Services, provide a framework for exposing Java classes as endpoints for Flash Remoting and you get automatic mapping between your ActionScript and Java domain objects.

However, Flex is not in any way tied to Java, and you can easily serve a Flex application from IIS. Flex's HTTPService class asynchronously consumes XML, JSON or SOAP served from .NET Web Services, REST, or WCF. In this way you'll continue to use your IIS and .NET server infrastructure and skills, perhaps with a thin facade layer to serve the data in the format your Flex application expects. Furthermore, there is an open source implementation of AMF: FluorineFx. It comes complete with framework libraries and wizards for generating and configuring an ASP.NET web application that serves AMF. Writing a remote service for a Flex application becomes little more than writing your class and marking it with the appropriate attributes. I'd highly recommend checking out this option if you want to keep using C# on the server. AMF is more efficient than XML or JSON, and you'll have the power of using strongly typed ActionScript domain objects in your Flex tier without needing to write the mapping layer yourself. Pushing data to the browser is an option with Lightstreamer, RTMP, or sockets with a custom protocol.

Architecture and Design Patterns
As with any platform, architecture and design plays a larger role as the complexity of your application increases. This is one of the places where your existing experience will translate very well, and you'll be better off than Flex developers coming from the web world.

One of the biggest problems we need to circumvent is that of your entire application becoming housed within a few monolithic UI classes. The problem is even worse with Flex because, as mentioned, the code that you write along with your view can be put in a script block right in your MXML markup. This can be greatly abused just as code behind in WPF and other .NET platforms often is. I've seen more than one application consisting of a few grotesquely large MXML files with a few helper classes. Instead we need a way to write our applications in a clean and decoupled manner and achieve a proper separation of concerns.

There are a number of MV-x patterns used to provide basic architectural organization, often Model-View-Presenter for WinForms and Model-View-ViewModel (also called PresentationModel) in WPF. M-V-VM is the choice for WPF (over vanilla MVP) because of the platform's sophisticated databinding framework. As Flex also has a useable binding system, I've successfully applied M-V-VM to a large Flex project. The typical three-layer approach:

Service layer composed of classes that wrap Flash RemoteObjects (when using FluorineFx) or HTTPService classes for JSON or XML transfer. There should be service interfaces for all classes.

ViewModel layer that handles events from the views and exposes bindable properties that present a flat picture of the model data used in the view. These classes get injected with the service classes (of course talking to them through their interface to allow for mocking).

View layer composed primarily of MXML components with a minimum of ActionScript required to glue everything together. The primary purpose of this code is to create the ViewModel instance and direct event handlers from the UI controls into the ViewModel. Code that needs to stay very close to the view (such as drag and drop) can stay here as well.

I like to couple the above pattern with dependency injection to construct and inject instances of the viewmodel classes with their services and any other dependencies. This is still a rare technique in the Flex community, but is becoming more commonplace with several quite useable open source containers out there. SpiceFactory's Parsley and the Spring ActionScript container (formerly known as Prana) are great candidates for this.

Another architectural alternative is the Cairngorm framework, which is the Adobe approved framework for achieving the ideals set out above. You'll find many Flex projects that use it to varying degrees of success and pain. The main features of Cairngorm are a FrontController class with a set of commands that you write to handle the events, a ModelLocator singleton that provides a global access point to your model layer, and a ServiceLocator singleton for looking up instances of Remote Service wrappers. At first glance, Cairngorm feels a lot like a Java Struts MVC style framework (with FrontControllers and Commands), and may trick some more web developers into believing so, but this is not the case.

Cairngorm, like any framework, has some useful constructs and some frustrating ones, and one of the things that makes a framework useful is being able to incorporate the parts you want without making your whole codebase depend on the pieces you don't. While this is not a problem inherent in Cairngorm, many developers new to the framework utilize everything verbatim in the way that the tutorials and how-to's demonstrate. This tends to result in a congested code base with too much boilerplate code for Commands and Delegate classes, and lots of direct dependencies on the ModelLocater and ServiceLocator singletons. As we know that singleton classes are the enemy of flexibility and testability, this should make most of us cringe.

If you decide to leverage Cairngorm or take over a project already using it, remember to apply the good lessons you've learned in the .NET world. ViewModels are still worthy constructs to use with the framework, providing a place for handling events and exposing portions of your model that are local only to your specific component (they can be managed by the ModelLocator). Cairngorm is open source, so you can modify the FrontController to use your IoC container as the factory for your Command classes, so they are injected with the ModelLocator and service instances, rather than using the singleton method of accessing them. The Spring ActionScript container is already incorporating extensions to allow you to work around the messier parts of Cairngorm and is worth a look just for this reason.

Conclusion
As Silverlight and WPF mature and gain mainstream acceptance, Flex and Flash will undoubtedly be forced to evolve in a direction where they can stay competitive. It's likely that there will be further feature swapping and parallels between the two. If you do find yourself in a position where you or your team will need to work on a Flex application, don't feel that you will be throwing away what you know and starting from scratch. Rest assured that you will be in the best possible place to pick up the new framework as well as anyone, and can continue to build on the .NET infrastructure and support that you already have.