Mar 07

Spring ActionScript: Café Townsend sample application

ActionScript, Air, Design Patterns, Domain-Driven Design, Flash, Flash Builder, Flex, Flex Builder, Inversion of Control, Spring ActionScript 8 Comments »

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:

PLAIN TEXT
Actionscript:
  1. [Autowired]
  2. [Bindable]
  3. public var presentationModel:EmployeeLoginPresentationModel;

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:

PLAIN TEXT
XML:
  1. <object id="autowiringStageProcessor" class="org.springextensions.actionscript.stage.DefaultAutowiringStageProcessor"/>

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:

PLAIN TEXT
Actionscript:
  1. [EventHandler]
  2. public function logout():void {
  3.   var operation:IOperation = _authenticationService.logout();
  4.   operation.addCompleteListener(logout_completeHandler);
  5. }

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:

PLAIN TEXT
XML:
  1. <object id="eventHandlerProcessor" class="org.springextensions.actionscript.ioc.factory.config.EventHandlerMetaDataPostProcessor"/>

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:

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

Thoughts on Cairngorm 3 and Application Architecture

AS3Commons, ActionScript, Cairngorm, Design Patterns, Flex, Inversion of Control, Lessons learned, Microsoft, Spring ActionScript 13 Comments »

Cairngorm 3 was recently announced by Tom Sugden and Alex Uhlmann and has now been released in beta on the Adobe Opensource site.

Don't expect an updated version of the Cairngorm framework as you know it though. Cairngorm 3 is not aiming to be an MVC implementation, and thus moves away from what version 1 and 2 were, but now consists of a set of patterns and practices, together with a series of libraries that can help to solve common problems.

The Patterns & Practices Group at Microsoft have been promoting a similar mindset for quite some time actually: Prism - patterns & practices Composite Application Guidance for WPF

I can only encourage this decision as it is exactly how I personally think about application design and architecture, especially in Flex and AIR applications. This is also what we are trying to do with Spring ActionScript: our main goal is to provide a solid Inversion of Control container that supports multiple configuration options (XML, MXML, metadata driven component scanning, ...) and promote it as a foundation to build applications (and frameworks), with or without your favorite MVC framework. Although we are working on a set of base classes that provide infrastructure for your application (under the name MVCS) with Application Events, Controllers, Abstractions for service layers, ... by no means do we want to market the Spring ActionScript framework as yet another MVC implementation. (You might wonder why we are calling it MVCS then, and I'm actually wondering the same... I guess marketing and buzzwords in the opensource world are also important. All kidding aside, the name is certainly subject to change).

What's in a name

Since this is a complete change of direction for the Cairngorm framework (which it actually no longer is) I would have expected a new name. Continuing to use Cairngorm as a name is in my opinion a bad move and will cause major confusion amongst developers and other people involved in the development process. I think the best thing for Adobe, or at least their Technical Services department, would be to let go of the name and choose a new, fresh name that moves away from the past. (Besides that, who can pronounce "Cairngorm".)

Dependencies

I noticed that some of the modules that Cairngorm 3 provides depend on other libraries/frameworks, and in general the Parsley application framework. While Parsley is certainly a major player amongst the IoC/application frameworks, and I sincerely respect the author's work, I don't think this is a good decision. In case you are wondering: Yes, I would say the same thing if they decided to depend on Spring ActionScript.

The usage and choice of a concrete dependency will have consequences for the adoption and integration of the libraries that Cairngorm 3 provides. Think about it: Why would you want to pull in Parsley, perhaps only to use some of its Reflection API, if you are already running on Spring ActionScript or any other IoC container?

We, the Spring ActionScript team, have actually questioned ourselves about this in the past and have therefore decided to move all the common and reusable code from Spring ActionScript into a set of libraries known as the AS3Commons project. In that respect, I'm a bit disappointed that for instance the AS3Commons Reflect library is not used for reflection purposes, since I think it is more abstracted and unintrusive than a subset of an all-encompassing application framework. Perhaps this may be our fault of not promoting the libraries and the project enough. However, I certainly think that AS3Commons could be a wonderful project and would help to provide common libraries not only to Flex and AIR developers, but to ActionScript 3 developers in general, if it were embraced by the community.

Flex and MVC

Given that RIA technolgies are still evolving at a very fast pace, it is really remarkable to see the huge amount of MVC implementations appear. Not specifically aimed at Cairngorm (at least the previous versions), but rather at almost all MVC architectures available for Flex development, my personal feeling and experience is that the use of MVC architectures in the Adobe RIA space is almost a dogmatic thing and is not needed in most cases. The problem is that people just take an MVC framework as it is and implement it in their applications. More than often not questioning whether or not its usage is justified. Things that could easily and cleverly be solved are ripped apart across layers of the architecture, introducing levels of indirection that are in most cases not needed. The only thing they add is complexity and counter-intuitive development practices.

One of the main arguments for using an MVC framework is that the code is "easy to understand". Of course the code will be easy to understand if you have been developing with the framework of choice for the N-th time or if you have been digging into the code for a serious amount of time, but ask a newcomer to look at the code and try to explain to you what it is actually doing... I think you'll be surprised by the responses.

I'm not saying that the use of a particular MVC framework is de facto a bad thing, but the "religious" use and the blind adoption and implementation make a framework a killer for your application. I would encourage everyone to start their next project without an MVC framework and just use the Flex framework with a healthy knowledge of design and presentation patterns. And even if you are using an MVC implementation, think about each layer you introduce, why you need it and the pros and cons it brings.

Conclusion

It's good to see that Adobe is rethinking their approach to RIA architecture and development practices. I also hope that they will be more open to community input and feedback than they were in the past. Although they did several attempts at engaging the community, I don't think they really succeeded in that. If not open enough, people will just continue to fork the "framework" and provide extensions that will end up in alternative implementations anyway.

I'm looking forward to seeing how all of this evolves.

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

Combining Factory and Strategy patterns

Design Patterns, Inversion of Control, Prana 5 Comments »

We often run into a scenario at work where we have to create an object from xml. More specifically we are parsing xml files with exercise (or assessment item) data to a concrete exercise type like a MultipleChoice, FillGaps, HotSpot, etc. The thing is that we are supporting several xml dialects for the same type of exercise and we end up with a lot of parsers. On top of that we also need to be able to decide on a per project basis what xml dialects are supported (a customer may only be allowed to use dialext X for exercise Y). In the next lines I will try to explain the way we manage and configure the objects that are involved in this process.

The basic idea is that we create a factory, let's call it ExerciseFactory, and define a createFromXML() method on it that takes an xml object as its input and "creates" a concrete exercise as its output. The factory is basically an xml parser. It works as follows:

PLAIN TEXT
Actionscript:
  1. var exerciseFactory:ExerciseFactory = new ExerciseFactory();
  2. var exercise:Exercise = exerciseFactory.createFromXML(xml);

Exercise is the base class for all exercise types like MultipleChoice, FillGaps, etc. The given xml object will be in a format that corresponds to such a concrete type. The factory however needs to know what the given xml is and what concrete exercise type it should return. The easiest way to handle these different xml dialects is with a switch on some property of the xml data. This results in code similar to this (in the ExerciseFactory class):

PLAIN TEXT
Actionscript:
  1. public function createFromXML(xml:XML):Exercise {
  2.   var result:Exercise;
  3.   switch (xml.someProperty) {
  4.     case multiplechoice-dialect-a:
  5.       // parse type MultipleChoice with dialect a
  6.       break;
  7.     case multiplechoice-dialect-b:
  8.       // parse type MultipleChoice with dialect b
  9.       break;
  10.     case multiplechoice-dialect-c:
  11.       // parse type MultipleChoice with dialect c
  12.       break;
  13.     case fillgaps-dialect-a:
  14.       // parse type FillGaps with dialect a
  15.       break;
  16.     case fillgaps-dialect-b:
  17.       // parse type FillGaps with dialect b
  18.       break;
  19.     default:
  20.       throw new Error("Cannot create exercise for the given xml object.");
  21.   }
  22.   return result;
  23. }

Although this works, it is certainly bad design since it is code that is hard to maintain and manage. If we need to add or remove some parsers, we have to modify this code which is buried deep inside some package hierarchy. We can't change this behavior at runtime since the parsers are hardcoded into the switch/case.

We could solve this with a mapping configured inside the ExerciseFactory. As its key, it contains the value of the property in the xml data we did the switch on. As its value it contains the class or an instance of the parser. This results in something like the following:

PLAIN TEXT
Actionscript:
  1. public function ExerciseFactory() {
  2.   this.map = {};
  3.   this.map[multiplechoice-dialect-a] = new MultipleChoiceDialectAParser();
  4.   this.map[multiplechoice-dialect-b] = new MultipleChoiceDialectBParser();
  5.   this.map[fillgaps-dialect-a] = new FillGapsDialectAParser();
  6. }
  7.  
  8. public function createFromXML(xml:XML):Exercise {
  9.   var parser:ExerciseParser = this.map[xml.someProperty];
  10.   return parser.parse(xml);
  11. }

Ok this seems better, but we can't configure the parsers externally since they are coded in the contructor. Let's externalize this by passing in the map to the constructor and additionally create a method for adding a parser.

PLAIN TEXT
Actionscript:
  1. public function ExerciseFactory(map:Object) {
  2.   this.map = map;
  3. }
  4.  
  5. public function addParser(key:String, parser:ExerciseParser):void {
  6.   this.map[key] = parser;
  7. }
  8.  
  9. public function createFromXML(xml:XML):Exercise {
  10.   var parser:ExerciseParser = this.map[xml.someProperty];
  11.   return parser.parse(xml);
  12. }

This is a neat implementation. We're setting a behavior or strategy for the parser in the factory at runtime, based on some configuration. But it has a drawback: the name of the property (xml.someProperty) in the xml data we use as a key in our map always needs to be the same for the different xml dialects. Unfortunately, we can't really control this because a new dialect might be used one day that does not contain the property.

To solve this, let's add another method to our parsers: canCreate(xml:XML):Boolean. As a parameter, it takes the xml data and then checks if it can parse the data by looking into the xml structure. Finally, it returns a boolean indicating whether or not the xml can be parsed. This way, the parser decides for itself what portions of the xml data to check instead of just the one property mentioned earlier.

To force this behavior upon the parsers, we can create an interface, IExerciseParser, and then let every parser implement it:

PLAIN TEXT
Actionscript:
  1. public interface IExerciseParser {
  2.   function canParse(xml:XML):Boolean;
  3.   function parse(xml:XML):Exercise;
  4. }
  5.  
  6. public class MultipleChoiceDialectAParser implements IExerciseParser {
  7.   public function canParse(xml:XML):Boolean {
  8.     // check the xml structure
  9.   }
  10.   function parse(xml:XML):Exercise {
  11.     // parse the xml to a MultipleChoice
  12.   }
  13. }
  14.  
  15. public class MultipleChoiceDialectBParser implements IExerciseParser {
  16.   public function canParse(xml:XML):Boolean {
  17.     // check the xml structure
  18.   }
  19.   function parse(xml:XML):Exercise {
  20.     // parse the xml to a MultipleChoice
  21.   }
  22. }
  23.  
  24. public class FillGapsDialectAParser implements IExerciseParser {
  25.   public function canParse(xml:XML):Boolean {
  26.     // check the xml structure
  27.   }
  28.   function parse(xml:XML):Exercise {
  29.     // parse the xml to a FillGaps
  30.   }
  31. }

We can now change the implementation of the ExerciseParser. We will remove the map because we will no longer be checking on a key to get a parser, but the parsers will check for themselves.

PLAIN TEXT
Actionscript:
  1. public function ExerciseFactory(parsers:Array) {
  2.   this.parsers = parsers;
  3. }
  4.  
  5. public function addParser(parser:IExerciseParser):void {
  6.   this.parsers.push(parser);
  7. }
  8.  
  9. public function createFromXML(xml:XML):Exercise {
  10.   var result:Exercise;
  11.   for (var i:int = 0; i<this.parsers.length; i++) {
  12.     var parser:IExerciseParser = this.parsers[i];
  13.     if (parser.canParse(xml)) {
  14.       result = parser.parse(xml);
  15.       break;
  16.     }
  17.   }
  18.   if (!result) {
  19.     throw new Error("Cannot create exercise for the given xml object.");
  20.   }
  21.   return result;
  22. }

... and configure our exercise factory before using it:

PLAIN TEXT
Actionscript:
  1. var exerciseFactory:ExerciseFactory = new ExerciseFactory();
  2. exerciseFactory.addParser(new MultipleChoiceDialectAParser());
  3. exerciseFactory.addParser(new MultipleChoiceDialectBParser());
  4. exerciseFactory.addParser(new FillGapsDialectAParser());

What we have achieved now is that we can add new parsers that support new xml dialects without the need to alter the code of the ExerciseFactory. All we need to is create a new parser, let it implement the IExerciseParser interface and it to the ExerciseFactory.

Additionaly, configuring the ExerciseFactory in a Prana application context is a piece of cake:

PLAIN TEXT
XML:
  1. <objects>
  2.   <object id="exerciseFactory" class="ExerciseFactory">
  3.     <constructor-arg>
  4.       <array>
  5.         <object class="MultipleChoiceDialectAParser"/>
  6.         <object class="MultipleChoiceDialectBParser"/>
  7.         <object class="FillGapsDialectAParser"/>
  8.       </array>
  9.     </constructor-arg>
  10.   </object>
  11. </objects>

Hope you enjoyed this. Don't hesitate to leave questions or comments. Have fun coding!

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

Domain-Driven Design, Thoughts?

ActionScript, Book reviews, Design Patterns, Flex 8 Comments »

Domain-Driven DesignI'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.

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

Typesafe Enum Pattern in AS3

ActionScript, Design Patterns, Flash, Flex 5 Comments »

I was trying to create a typesafe enum today to hold a Debit and Credit value and realized it could not that easily be done in AS3. In AS2 or in Java (prior to Java 5 when there was no enum construct) you could do the trick by making the constructor of the enum private and instantiate the values as static constants. (See this blog post for an AS2 example.)

Read the rest of this entry »

Add to Bloglines - Digg This! - del.icio.us - Stumble It! - Twit This! - Technorati links - Share on Facebook - Feedburner
 
Previous Entries
WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in