Number 3 on my list of Cairngorm tips is the Data Translator pattern. I’d like to preface my explanation of the pattern with a discussion about web application domains.
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.
One of my preferred ways of dealing with this since I’m usually working with XML data coming off a service bus is to have my VOs “wrap” the XML instead of translating back and forth at the delegate layer. The getters/setters deal with expected data types but underneath they’re manipulating the received XML using e4x. Of course it all depends on where the application is doing the heavy lifting, but imagine translating a hundred objects, setting a property on a few of them, then translating back to XML at the service layer. If you keep it native XML underneath and wrap then you’re only dealing with the overhead of e4x on the properties you’re accessing.
How would you go about parsing an arbitrary XML document that you don’t and can’t know its structure?
@danielggold
Yeah man.. a proxy technique is great in this case. The only gotcha is if you have large volumes of data you’ll use even more ram due to the additional object instances for all the proxies.
Optimization is always a trade off. In the wrapper solution you use more ram but defer execute. In the data translator solution more processor time is used up front with the gain of less ram used and faster access to the data.
As I said in the post, a good engineer considers the many viable solutions to this problem on the basis of what you’re trying to accomplish in your application.
Cheers
-adam
@Anonymous
Well… you really can’t. If you want typed objects, you need to know the schema before compile time.
Hi Adam,
Very nice example, and thank you for taking the time to post on Cairngorm related topics – as there hasn’t been much blogging going on in this space for some time.
I essentially use the same pattern of data translation and abstraction but with a factory implementation. Whats nice about this approach is you can leverage Dependency Injection to configure the Factories, so for example, if we needed to translate our domain models to another format other than XML we can do so by changing the Factory implementation via the IoC container. In this way client code need not be modified as the change would be implemented transparently to the clients implementation.
Best,
Eric
@Eric
Thanks for the comment. That’s a cool approach.. If you blog about it, be sure to link from this post. Theoretically I’m a big fan of IoC like this, but practically I find that the data translation layer doesn’t change that often. However, every app is different and if it’s an easy pattern to implement the added flexibility is definitely a nice-to-have.
Thanks again
-adam
Nice post! I was just wandering the halls of Google results for a great idea for handling XML in cairngorm. I can’t wait to try this out. Thanks for contributing.
Interesting article you got here. It would be great to read something more concerning that theme. Thanx for giving that data.