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:
-
[Autowired]
-
[Bindable]
-
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:
-
<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:
-
[EventHandler]
-
public function logout():void {
-
var operation:IOperation = _authenticationService.logout();
-
operation.addCompleteListener(logout_completeHandler);
-
}
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:
-
<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
Christophe Herreman is a software developer living in Belgium. He's working on high-end Flex and AIR solutions at 
Recent Comments