rethinking Flex Data Management - continued

This is part 2 of the series of posts dedicated to Flex Data Management and our implementation of the functionality. In part 1 I gave a high level overview of various FDMS moving parts, their configuration and some basic client-side API. To review, a typical FDMS solution would include the following:

1. Managed data - traditional RDBMS or an in-memory data store.
   
2. ValueObject (VO) class - a class representing a row in the targeted data table.
3. Data Access Object (DAO) class - a class responsible for the execution of the basic data store operations (CRUD), materialization and serialization of the value objects.
4. Data assembler - an interface between FDS and the user's data management application on the server-side. Typically a class encapsulating high level operations requires by FDMS.
   
5. Destination configuration - contains a client-side facing representation of the data assembler as well as metadata used by FDS to enable client synchronization and some additional features.
6. Client-side ValueObject class - maps directly to the server-side ValueObject (2). Represents a row of managed data.
7. Application specific client-side data management logic - this is the code you add to handle view updates, synchronization and conflict resolution events.
8. Generic client-side logic data management logic - encapsulated in the form of the mx.data.DataService class as well as some auxiliary classes and APIs.

The diagram below demonstrates how these components relate to each other:

As you can see, FDMS is a fairly complex system with a lot of moving parts. The system is designed to provide an end-to-end data management solution with some very powerful features like multi-client synchronization, conflict resolution and support for the disconnected mode. As I mentioned in the previous post, WebORB provides a basic implementation of the Flex Data Management functionality. Since we introduced support for FDMS last year, we have been running into multiple scenarios where it was rather hard to explain and justify the benefits of the approach shown above. The resistance is mostly due to the following factors and limitations:

1. Significant development effort. A developer has to write a lot of supporting code: server value objects, DAOs, assemblers, port the server VOs to the client side (which may need to be done by a client-side developer). Indeed, from the list shown above, the following items are developers responsibility: 2, 3, 4, 5, 6 and 7.
2. Lack of programming flexibility. We hear this one over and over. Data driven rich internet applications DO require some flexibility to create custom data management operations. Consider a scenario where a single request from a client must update multiple data stores, perform a select query, find a record and link it to some other data object. Oh, and all of this must happen in the context of the same transaction. It may be possible to achieve all this, but it is definitely not straight-forward.
3. Non-expressive API. Client-side interface with the FDMS system is encapsulated mostly in the mx.data.DataService class. The class is rather compact and includes support for all basic data management operations. Since the API is centralized in a single class, it makes it less intuitive and not as expressive. It especially becomes obvious for anyone familiar with the frameworks like Ruby on Rails' ActiveRecord.

With these limitations in place, if you were to put side-by-side a Rails developer and a Flex server developer tasked to come up with a similar solution for their respective environments, the Rails developer would be much further along in the same amount of time. The main reason is Rails does a lot more to get you started and then let's you stay super productive. There is no reason why Flex developers cannot enjoy the same.

So we had an idea to make something that would nicely fit the Flex programming model, provide the same great features available in FDMS, address the problems shown above, offer the best features available in most popular data management frameworks like Rails's ActiveRecord and Hibernate and best of all be available for all server platforms and programming environments. The next post will go over what we came up with for our new data management solution for Flex. Stay tuned.

Technorati tags: WebORB, Flex, FDMS, Flex Data Management