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 the FeWeb presentation I did on our Flex development, I thought it was worth compiling a list of the tools and technologies we use. This is certainly not a complete list of all tools out there, but just the ones we use in our day to day development.

All descriptions were taken from the tools’ sites.


Tools

- Flex Builder (Plugin): Adobe® Flex™ Builder™ 2 is an Eclipse™ based IDE for developing rich Internet applications (RIAs) with the Adobe Flex framework.
- Eclipse: an open source community whose projects are focused on building an open development platform
- Ant: a Java-based build tool. In theory, it is kind of like Make, but without Make’s wrinkles.
- Flex Ant Tasks: provide a convenient way to build your Flex projects using an industry-standard build management tool.
- ASDoc: a command-line tool that you can use to create API language reference documentation as HTML pages from the classes in your Flex application.
- Cruise Control: a framework for a continuous build process. It includes, but
is not limited to, plugins for email notification, Ant, and various source control tools.

Frameworks

- Cairngorm: a lightweight yet prescriptive framework for rich Internet application (RIA) development.
- PureMVC: a lightweight framework for creating applications in ActionScript 3, based upon the classic Model-View-Controller design meta-pattern
- Prana: an Inversion of Control (IoC) Container for the Flex Framework

Unit Testing

- FlexUnit: a unit testing framework for Flex and ActionScript 3.0 applications. It mimics the functionality of JUnit, a Java unit testing framework, and comes with a graphical test runner.
- Flex Unit Optional Ant Task: Allows you to hook FlexUnit into a Cruise Control cycle and extract test reports

Libraries

- Corelib: consists of several basic utilities for MD5 hashing, JSON serialization, advanced string and date parsing, and more.
- Flexlib: a community effort to create open source user interface components for Adobe Flex 2

Remote Gateways

- WebORB: facilitates connectivity between rich clients created with Flex, Flash or AJAX and server-side applications developed with .NET, Java, Ruby on Rails, PHP or XML Web Services.
- Fluorine: an open source .NET Flash Remoting Gateway.

Yesterday evening, the 5th annual FeWeb conference took place in Edegem. I did a session on our Edumatic product development with Flex and what tools we use on a daily basis. Below is a download link for those interested in my presentation files. The slides contain some useful links to the tools mentioned.

feweb-12-12-2007.ppt (273 kb)
feweb-12-12-2007.pptx (187 kb)

For a review of the conference I can recommend the following post by Peter Elst: FeWeb - Flex, Silverlight, AIR and more.

Yesterday we had a very cool user group meeting where Mike Chambers and Mike Downey talked about Apollo and Flash CS3. I won’t go into much detail because Koen De Weggheleire already did. You can read his extended review about Mike Chambers on Apollo and Mike Downey on Flash CS3.

Since we are creating a lot of cross-platform (e-learning) applications, I was especially interested in Apollo. All the features we were shown looked awesome. The fact that you can render HTML inside a SWF and then actually have access to the HTML’s DOM is a killer feature (Flash SCORM player anyone?). Also, the ease of distributing Apollo apps and being able to create OS specific installers is very nice.

The only thing that is still missing in my opinion is database support. Although Apollo apps are Internet enabled, it would still be great (even necessary) if you could work offline and have an offline database. To accomplish this in our current apps, we need to create a Zinc version with an MS Access database and a Director version with a V12 database. This is too much work and leads to too much errors. If Apollo would solve this problem, I would be a very happy man. Besides my own happiness, I feel like it is a necessary feature in order for Apollo to be taken serious, especially by desktop developers.