Christophe Herreman

I have been thinking about some of the concepts and patterns described in the Domain-Driven Design book and how they could be implemented in a Flex or AIR environment.

One thing that interests me in particular is the use of a Repository as a container for Domain Objects. In short, a Repository is responsible for fetching, persisting and manipulating objects. Its intent is to shield the client from the implementation details of the data storage or the remote services that are used to get and manipulate objects.

However, there seems to be a fundamental problem in creating an ActionScript implementation. Since remote services are handled asynchronously, it is impossible to create a Repository as it is originally described by Eric Evans.

Here’s a snippet of a post (by myself) on the DDD list:

Would it be correct to assume that repositories don’t make much sense if you are dealing with async remote calls? Or should I say that async data fetching is a problem currently not addressed by DDD? Quoting Eric Evans in the DDD book (p. 157): “The client of a REPOSITORY should be given the illusion that the objects are in memory.”. That being said, it is no problem to call a method on a repository and have it return the objects immediately if the objects are in memory. But, if the objects are sent back asynchronously, the whole point of encapsulating that behavior is gone since the client needs to “listen” for a response on the repository. So it knows about the implementation details of the repository.

As a reply, someone offered to try to make the call synchronous by waiting for a result. Although I think that might work, for instance by entering a loop until the result is received, I’m not completely sure as I haven’t tried this. Here’s my reply:

The problem I see is that the UI will be locked/frozen until the response is received because the code runs in a single thread within the Flash player. That means it won’t be possible to create a (animated) loading screen to give the user some visual feedback. This would probably not be a problem with remote calls that return a small amount of data and a fast remote connection, but it certainly will be a (usability) problem if the connection is slow or if we are loading large chunks of data.

Conclusion

So my conclusion at this moment is that implementing Repository in Flex doesn’t make much sense since the client still needs to know about some of the technical details of the implementation. Locking the UI would most certainly lead to usability problems (if it would even be possible). On the other hand, a Repository could be perfectly implemented as intended in an AIR application that uses an embedded SQLite database and synchronous calls, but the UI would also be locked.

Thoughts?

Following up on Douglas McCarroll's modified Cairngorm Store update, I thought I'd take this a step further and add a Prana application context to configure the business delegates and the service locator. This example has support for mock delegates that contain hardcoded local data and is also able to connect to php services using Remote Objects and AMFPHP.

This examples replaces the older Cairngorm Store example that was configured to work with AMF0 and Renaun Erickson's RemoteObjectAMF0. It now uses the latest beta version of AMFPHP and the AMF3 protocol. The services are hosted on this domain so you don't need to setup AMFPHP in order to see this in action.

The code is currently in svn and can be checked out at http://prana.svn.sourceforge.net/viewvc/prana/trunk/samples/PranaCairngormStore/. This sample will also be included in the next release.

Here's a snippet from the readme file:

***

The following files have been added/changed in order to add Prana configuration support for business delegates and service locator:

* Main.mxml: added application context loader and forced compilation of configured classes

package com.adobe.cairngorm.samples.store.business
* BaseBusinessDelegateMock.as: implements IResponderAware, removed responder constructor argument
* CreditCardDelegate.as: extends AbstractRemoteObjectDelegaten, implements ICreditCardDelegate
* CreditCardDelegateMock.as: implements ICreditCardDelegate
* ICreditCardDelegate.as: interface for credit card delegates
* IProductDelegate.as: interface for product delegates
* ProductDelegate.as: extends AbstractRemoteObjectDelegaten, implements IProductDelegate
* ProductDelegateMock.as: implements IProductDelegate

package com.adobe.cairngorm.samples.store.commands
* GetProductsCommand.as: added delegate lookup via ShopModelLocator
* ValidateCreditCardCommand.as: added delegate lookup via ShopModelLocator

package com.adobe.cairngorm.samples.store.model
* ShopModelLocator.as: added creditCardDelegate and productDelegate variables to configure business delegates

***

As a result, we can now lookup the implementation of our business delegates in the commands instead of instantiating new ones. The commands are completely unaware of the implementation of the business delegates. One note though: since we are not creating new delegate instances, we need to set the responder as a property of the delegate before calling its methods.

Here's how the application is configured in the application context to use the mock delegates:

And here's how the remote object delegates and the service locator are configured:

I'm currently reading Eric Evans' book "Domain-Driven Design: Tackling Complexity in the Heart of Software". Domain-Driven Design, or DDD, is about seeing the role of the model as the crucial part of a software project, about creating domain logic that is based on the model, about creating an ubiquitous language that is to be used by all team members (even non-technical) and much more.

This is exactly how I have been thinking about application design for quite some time now, especially since I moved from developing web applications that primarily dealt with CRUD operations to Flash platform development. The Flex projects I have been working on for the last years all have pretty complex domain models and they require a whole different approach and discipline in thinking about application architecture.

This might seem very obvious, but in a highly visual environment like Flex/Flash it is very tempting to focus on the User Interface first and hack together a "domain model" that really has a less important role. You end up with a weak model that is hard to expand, debug and Unit Test and in the end it makes you lose a lot of time.

This also gets me to think about the popular architectural Flex frameworks out there. In my opinion they break the principles of DDD by either providing base model classes that your domain model should be based on (Proxies in PureMVC) or by promoting the use of Value Objects as a domain model (Cairngorm).

We use Cairngorm in our projects but we (almost) never work directly on the Value Objects (or should I say Data Transfer Objects). Before an entity or a VO is sent or received, it is pulled through an Assembler that translates it both ways. It is obviously more work to create this mapping mechanism, but my experience is that it really pays off in the end. For instance, if you use remoting and are sending out or receiving domain objects, you have to make all your properties public or you must create getter/setters for them, you can't properly use constructors since the AMF mapping relies on properties, you have to expose your arrays or collections in order to map them, ... This makes the domain model more fragile, something you want to avoid as much as possible.

Another thing that is worth mentioning is the use of Repositories in DDD. Repository is very similar to the ModelLocator known in Cairngorm, but instead of having a singleton model, a Repository is created for a single domain entity. The Repository contains query methods to retrieve objects based on certain criteria. It also promotes not having too much associations between objects because those are hard to maintain and provides association lookup methods.

I'll try to post an in depth review when I finished the book.

In the meantime, I wonder how many Flex projects are actually dealing with complex domain models and I'm even more interested in what frameworks are being used, if any. If you have any experiences or thoughts to share, please feel free to comment.

I put up the slides of the Prana presentation I did on the Adobe Usergroup - AIR Pre-Release Tour. You can download them at the Talks section or here (direct download).

Further, a number of people have blogged about the meeting:
- Ward de Langhe
- Gilles Vandenoostende
- Wim Vanhenden

I’m proud to announce that Prana 0.4 has been released.

Some of the key features and updates:

• major update to the core IoC container
• support for PureMVC
• several bugfixes and minor improvements

General info: http://www.pranaframework.org
Download: SourceForge Download Page

Changes in version 0.4 (26.01.2008)
-----------------------------------

General
* introduction of PureMVC support
* added PureMVC sample application
* nightly builds available at http://prana.herrodius.com
* fixed config.xsl to ignore _svn folders

Package org.pranaframework.cairngorm
* fixed early dispatching of events in EventSequence

Package org.pranaframework.collections
* added "remove" method to IMap and Map
* changed "size" and "values" methods to getters
* Map now extends Dictionary instead of Proxy

Package org.pranaframework.config
* AppSettings now extends Proxy instead of Map

Package org.pranaframework.ioc
* added check for valid IList before creating cursor
* added "isLazyInit" and "initMethod" properties to IObjectDefinition and ObjectDefinition
* added support for init method in ObjectContainer
* added "removeObjectFromInternalCache" method
* enhancements to "getObject"
* added post processing capabilities to ObjectContainer

Package org.pranaframework.ioc.factory
* added IObjectContainerAware

Package org.pranaframework.ioc.factory.config
* added ObjectContainerAwarePostProcessor
* added LoggingTargetFactoryObject

Package org.pranaframework.ioc.parser
* added support for lazy init and init method in XmlObjectDefinitionsParser
* fixed "parseProperties" because of Map refactoring, keys were not strings in XmlObjectDefinitionsParser

Package org.pranaframework.puremvc
* initial release

Package org.pranaframework.utils
* added Parse port from the Fit framework
* added HtmlUtils utility methods for working with html
* added "isExplicitInstanceOf" method to ObjectUtils