Do DDD Repositories and Flex make sense?

ActionScript, Air, Domain-Driven Design, Flex Add comments

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?


Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner
 

6 Responses to “Do DDD Repositories and Flex make sense?”

  1. Tony Hillerson Says:

    I may be really naive here, but it seems like the asynchronous nature of AS shouldn’t be a problem, as long as you make an allowance for a slight shift in the technical details of implementing a repository.

    If, as I’m assuming, dealing with a repository is all about requesting the persistence of changes to domain objects or requesting the objects themselves, can’t we use a Responder pattern and binding just as with classic service calls? The view doesn’t need to know anything more, it just uses binding to keep up to date with changes to objects.

    Again, I’m not familiar with all the requirements of DDD, so I may be missing something fundamental.

  2. EECOLOR Says:

    “if it would even be possible”

    Yes, it is possible, but results in locking up your system aswell. The Flash player tends to do things as fast as it can. Until we have some kind of a thread model and are able to do infinit loops without crashing the player we will not be able to turn async. into symc.

    Greetz Erik

  3. Christophe Says:

    @Tony: Indeed, the only thing we could do is allow the repository to handle async requests and give it an api that is able to work with AsyncToken and IResponder.

    @EECOLOR: Having a thread model in the Flash player would certainly be useful for such scenarios. I wonder if the player team has been thinking about adding threading support.

  4. Ole Christian Langfjæran Says:

    I’ve also tried to clutter my small brain around this topic, and the asynchroness of it all makes it a grim task I think.

    I tried it on some pretty small code where the domain object was able to persist itself. Asynchronosly of course. The thing I ended up doing was that the repository method save had an optional parameter where I could inject a function which should be called after the repository had done it’s bit. The various views could then inject handler-functions for when the domain-object was persisted.

    Not the prettiest of sights, but it worked well enough :)

  5. Daniel Harfleet Says:

    Christophe,

    maybe you could use some kind of Proxy pattern and just have the view display a placeholder, a bit like data management (Flex/LCDS) or FilePromises (AIR 2) do ?

  6. Christophe Says:

    @Daniel: I’ve experimented a bit further with this and implemented some repositories with the Operation API we have in Spring ActionScript. I wrote some details about that API here: http://www.herrodius.com/blog/284

Leave a Reply

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in