Christophe Herreman

A new Spring ActionScript sample application is now available. This is the Café Townsend application, originally created as a sample application for the Cairngorm framework, that we ported to Spring ActionScript. This should make it easier to compare this implementation with the implementations of some of the other frameworks.

Open the Café Townsend sample.
(Be sure to check the source by right-clicking and choosing "View Source" from the context menu, click here to go to the source directly.)

Download the Flex/Flash Builder project and sources.

Discussion

In what follows, we will discuss the implementation details and motivate certain choices made in this design.

Package Structure

The first thing you might notice is the package structure, that might seem a bit odd at first since it is different from what most frameworks use or prescribe. This example follows the Layered Architecture, described by Eric Evans in the book Domain-Driven Design: Tackling Complexity in the Heart of Software (recommended reading). This architecture makes it easy to detect and apply the different layers of the application and forces us somewhat to have a clean separation of the responsibilities of each layer.

The layered architecture consists of four layers, as shown on the image below:

• Presentation Layer: contains the user interface (the view component and in this example the presentation models)
• Application Layer: coordinates the application and forms a communication channel between the UI and the domain
• Domain Layer: the core of the software. This layer defines the entities and repositories/services that form the business logic of the application. For the most part only the interfaces for the services will be written here. This layer does not contain any implementation details.
• Infrastructure Layer: provides implementation details for all other layers. Concrete implementations of services will be put here.

Note that it is certainly not needed to structure your application like this. Spring ActionScript does not impose or prescribe this structure, but we certainly think it is useful and wanted to introduce it in this example. Also note that while we have applied this architecture as packages in the same application, you might want to create different swc's or libraries for each of these layers so that they can easily be reused.

Presentation Layer & Presentation Models

This example uses the Presentation Model (PM) as the main presentation pattern for the UI layer. The PM allows us to extract all state and controller logic for the view into a separate class that is view agnostic. A view component contains a reference to its corresponding PM and delegates all UI actions to it. The view component can either instantiate the PM directly, or it can be given one, either by a parent component or by having it "injected" by the Spring ActionScript framework. The process of automatically injecting properties into a (view) component is known as "Autowiring" in Spring ActionScript. Note that since the PM is not a UI component and does not know anything about the view, it can be easily unit tested.

An example of autowiring can be found in the EmployeeLogin.mxml class:

The PMs used in this example will either delegate directly to the business logic (for instance for loading the employees) or will delegate to the Application Layer (for instance for logging the user out of the application). Here again, there is no strict rule to follow, but you can decide for your own what approach seems the bests.

Note that autowiring is disabled by default. This is because in bigger applications, there might be a significant performance hit when autowiring is used. It is adviced to finetune the autowiring by configuring the autowire processor to include or exclude certain classes. To enable autowiring, simply add the following to the XML configuration:

Application Layer

In some cases, the UI will delegate responsibilities to the Application Layer. Since the UI does not know about this layer, it needs a loosely coupled way of communicating with it. The communication channel that provides this capability in Spring ActionScript is the EventBus. It is implemented on top of Flash's event dispatching capability and forms a centralized medium for component and layer interaction.

In the example, the code behind the Logout button will dispatch an event via the EventBus. The application controller listens for this event and will handle it by invoking the logout method on the authentication service. Notice that the application controller takes the authentication service as a constructor argument and that the service is typed to the interface IAuthenticationService. The actual instance is provided in the (XML) configuration, were both the application controller and the authentication service and defined and linked to eachother.

Notice that the application controller does not explicitely listen for the logout event. Instead, it is sufficient to create a method and annotate it with the [EventHandler] metadata. Spring ActionScript will then introspect the controller, pick up all annotated methods and link them automatically with the event received from the EventBus.

Here's what the logout method looks like in the application controller:

Notice that the name of the logout method corresponds to the event being dispatched, namely "logout" (see the ApplicationEvents class for that). You can however also choose the name of this method as you like and specify the name of the event as an attribute of the EventHandler metadata.

As with autowiring, the processing of the EventHandler metadata is not enabled by default. If you want to use this in your application, simply add the following to the XML configuration:

For more information on the EventBus, please refer to the documentation.

Domain Layer

The domain for this application is extremely simple. All it contains is an Employee entity and an employee service in the form of the IEmployeeService. Except for the actual entities of the domain, this layer does not contain any implementation details for the services it provides, but merely defines the interfaces for those services.

Infrastructure Layer

The infrastructure layer is where the technical details of the applications live. This layer provides the actual implementation of the services found in the other layers. Depending on the different contexts the application needs to be able to run in, you might provide different implementations of the services here. The implementations used in the application can then be defined the a Spring ActionScript Application Context. As an example, think of an application that needs to be able to connect to a set of services using Remote Objects in one scenario and needs to connect to a set of Webservices in another scenario. If we provide both implementations, we can easily reconfigure the application by changing the XML configuration of the application context.

Application Context

Once we have all components, we can bundle them together and prepare them to be used in the application. By doing this, we are configuring the context of the application. In Spring ActionScript this is done by instantiating a FlexXMLApplicationContext (in case you are working with Flex).

The application context in this example is configured using XML, but it could just as easily be configured using an MXML configuration. Both approaches have there pros and cons and you should decide what fits best for you project.

Looking at the Main.mxml class, which is the entry point of the application, we can see that a FlexXMLApplicationContext is instantiated and given the path to the external XML file (application-context.xml) that forms the application context's configuration. Now all we need to do is wait for the context to load before starting the application.

Conclusion

This example contains significantly less code than the original Cairngorm version. This is mainly because Spring ActionScript does not impose any strict architectural rules and provides the developer with plenty of choice for architecting things that best fit the application being developed. What might work in application A might not necessarily work well for application B or C. Being given so much freedom and choice might feel awkward at first, but you will notice that this is actual a good thing and you will benefit greatly from it.

If you have any remarks on this post, please leave them in comments or contact me. Whether they are errors, things that are unclear, or general questions... all feedback is welcome.

General information and document about Spring ActionScript can be found at http://www.springactionscript.org/

Related articles:

• The Operation API
• Spring ActionScript 1.0 RC1 Released
• Spring ActionScript Devoxx slides

---

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

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
 

A post on the Domain-Driven Design mailing list got me to reflect on a recent project we did in the domain of accounting. This was a completely new and unknown domain for us as a team and it sure took us a while to grasp the different domain concepts. After some meetings with the (Dutch) clients and as soon as we had enough understanding of the domain, we started developing.

(On a side note: I couldn't help but notice that our client was pretty inpatient whilst teaching us about accounting.)

As a company-department standard, we program all code in English since it feels the most natural given the fact that most (if not all) API's we use are also written in English. However, we quickly faced the following problem: What are the English translations of the different domain concepts we just learned as part of this accounting application? As a result, I spent a fair amount Googling around to find dictionaries with accounting terms and finally wrote down a translation scheme for the domain objects.

Although I'm pretty sure we got the correct translations of the domain objects, it felt awkward at times to work with the API we were creating. In fact, it made developing quite a bit harder because we had to constantly translate terms when we were talking amongst developers and when we were talking with the domain experts/the client at iteration meetings.

On the other hand, mixing Dutch and English code is also pretty awkward and could make the code hard(er) to read. So I'm still kind of undecided about what option to choose. I guess it depends on how transparent the translations of the domain objects are and how easily they are interchangeable.

Does anyone have any experience with this? How are or would you be handling this situation? Do you prefer sticking to English with the added complexity of dealing with domain object translations or do you develop in the language of the domain experts?

Damn you tower.

---

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