As Flex developers we’re often inclined to use server-side technologies like Blaze DS, LiveCycle DS, ColdFusion, amfPHP, RubyAMF because of the native object transfer layers that these technologies have available. The magic in these solutions is a binary format called AMF (Action Messaging Format). AMF allows disparate languages to communicate with native objects. For example, in a Blaze DS Java server project if I define a class that has the same public properties as a class definition in ActionScript, Java and ActionScript can transport data of this type and deal with the data as a native object instance in each layer. The benefits gained from native object data transfer are: compile time type checking, speed, and elegance. However, this post is not about AMF, but about the pattern of translating other data formats (like XML, CSV, JSON) into the Flex application domain.

An important distinction when implementing a Flex application is the separation of domains. In a typical web application there are several domains to think about, but for the sake of this example let’s look at two: the service layer domain and the UI domain. The distinction between these domains is important to ensure high standards of maintainability and modularity. It is essential to avoid a situation where a change in the service layer has major impacts on the implementation of the UI layer, and vice versa. The Data Translator pattern is a simple pattern, but an important concept for keeping these concerns separated.

In this example I will be using XML translated to ActionScript VOs (value objects). XML is a common format in the world of web services, and especially in Flex development, however this pattern can be used with nearly any data format that a service might expose. That’s enough setup, now let’s dig in to the Data Translator.

A Data Translator is a class with static methods for parsing data generated by the service domain into a format that is specific to the UI domain. Data Translators are typically invoked by Delegate classes. In my opinion, the Delegate layer is the appropriate place to handle data translation. If your Command class is dealing with data that is part of the service domain, you may need to rethink your architecture. Like nearly everything in any field of engineering, there are exceptions to this rule. If you are implementing an application that’s function is to display read-only data, XML can be a great format for that application. However, if your application involves modifying data that was retrieved from a service, value objects are usually the best solution.

So, let’s check out the example application:

View the Application | View the Source | View the Docs 

DataTranslatorExampleApplication – Defines a button that dispatches the GetItemsEvent, a console to show Cairngorm actions, and a DataGrid to show the result of the operation.

ItemsCommand – Invokes the getItems operation on the delegate class and by standard Cairngorm convention, updates the global model with the items returned by the delegate.

DataTranslatorExampleDelegate – This delegate is responsible for calling the service that responds with a collection of items. The items are returned in an XML format and then parsed by the ExampleDataTranslator class.

ExampleDataTranslator – Translates the XML payload into a set of objects of type Item.

Item – A value object that models the data of an “Item”

This pattern is a favorite of mine for dealing with the translation of data into a format for the UI application domain.

Up next, tip #2 Aggregated Commands.

My posts on team development will start from a beginners understanding of programming, working up to an advanced look at architecture and design.

First thing’s first: What’s this MVC thing?

MVC stands for Model-view-controller. MVC aims to separate, or decouple, data (model) from the user interface (view) and functional logic (controller). You can read a lot more about MVC on the Wikipedia.

How do we use MVC in an RIA (specifically a Flex app)?

Well thought out architecture and design is important at every level of the application, but an RIA is different than a web app of the past in one important way: state. In legacy (HTML script-based) web apps state is, for the most part, required to live on the server. In RIA development we are not bound by this requirement. We can build RIAs that have state at the client or the server or a hybrid of both. This one fact completely changes the complexity and importance of what once was merely the view. In RIA development the part of our application that lives at the client level is not just an HTML rendering of a view, it can be a fully functional stand alone application. The client in a RIA has many of the characteristics of a desktop application and that is why MVC applies at this level.

Why is this called a micro-architecture?

We refer to architecture and design patterns at the Flex level as a mirco-architecture frameworks because the Flex application is a piece in the larger picture of the entire application. The Flex app may talk to one or more web services, consume an RSS feed, stream video, show images from the web, and so on. All of these services fit into the larger architecture of the web app. These architectural decisions are also important but a little harder to talk about generically. So, since this is a Flex blog, when I speak of architecture I’ll really be talking about client micro-architecture.

Why do you want to use a micro-architecture?

Actually, sometimes you don’t. If you’re creating a very simple app (something like a widget or a banner ad) MVC might not be for you. However, if you’re creating something that models data retrieved from a service, allowing the user to manipulate that data, and displaying the data in interesting ways… MVC is really a good choice to make.

What you get

1. A code base that facilitates team development.
2. A skill that will make your team more agile in their development life cycles.
3. Source that has a high level of maintainability and interoperability.

Ok.. let me unpack those a bit.

1. Your code base will facilitate team development most simply because the team is now coding to a convention. MVC isn’t really the big deal here, it’s the fact that a convention was decided on. MVC does offer some nice things in regards to team development that I’ll talk about in other posts, but my point here is that convention keeps everyone on the same page.

2. Every learn how to play an instrument or a sport? Each of these skills involves mastering patterns. The more your team implements on the patterns in MVC, the better skilled they will be at it. My point here is really that MVC should also be viewed as a problem solving tool. When you get developers thinking about solving architectural problems in the same way, everyone can solve that problem faster.

3. Maintainability and interoperability… again this really goes back to convention. Your code will be more maintainable by your dev team if it’s built on convention. If you chose a convention that’s fairly mainstream, then you gain a level of developer interoperability. Meaning, training in a new team members on the way you implement requirements will be a lot easier if your using a convention and on top of that a standard convention. In Flex development, Cairngorm is a nice way to go. It’s not necessarily the best framework out there, but it seems to be the most widely adopted Flex micro-architecture.

I’ll be delving deeper into MVC and Cairngorm in my next posts.