Flex Article

An architectural blueprint for Flex applications

What kind of architecture lends itself to a Flex application?

Enough high-flown concept-mongering, already! What are some general strengths that an architecture should endow our Flex applications with? For my part, I would like to:

• Isolate the handling of state, presentation, action and communication for simplicity and clarity
• Accommodate frequent unpredictable changes as an application evolves
• Keep the UI and data model code as simple as possible, since that's where most of the changes are likely to occur
• Make it easy to develop and test any aspect of the application independently of the others
• Decouple and make programming tasks parallel so that they can be carried out by different people
• Provide a very responsive user experience with clear feedback and zero latency

To my mind the first goal, isolation and encapsulation, is the key to the others. Isolating concerns opens the door to accommodating change, because it puts boundaries on the ripple effects of changes within the code. Isolation makes modular development and testing easy. Isolation makes it easy to have different people work on different pieces. Finally, isolation makes it easier to envision ways of improving the user experience that are generalized and powerful.

Presenting the MVCS architecture

Keeping in mind the above goals, I now introduce an architecture that can deliver it to us. It's called the "Model-View-Controller-Service" approach, or MVCS for short.

The MVCS architecture is centered on that first, primary goal: "isolate state, presentation, action, and communication." Essentially, you break the application into four clean, separable large-scale components, one to isolate and encapsulate each of those four concepts. (I'm using the term component here in an architectural sense, meaning a family of related objects that share an overall responsibility; I don't mean an MXML component.) Table 1 summarizes those big MVCS pieces.

Table 1. MVCS architecture components

Component	Isolates concept	Encapsulates responsibility
Model	State	Model objects are what the application knows, comprising its state and its information about the world. When this state changes, events are dispatched to notify the View to update.
View	Presentation and Interaction	View objects are the interactive surface of the application, presenting live information in the Model to the user, and responding to user gestures by invoking actions in the Controller.
Controller	Action	Controller objects implement what the application does, modifying the Model to reflect those actions, invoking Services to communicate with the outside world, and making use of Views as needed.
Service	Communication	Service objects are how the application talks to the outside world, populating some objects in the Model with information received back from that world.

Figure 1 shows the same pieces and the major interactions between them.

Figure 1. Visual representation of the MVCS architecture

But... this is already way more abstract than I'd like. It's time to fill in those empty boxes with objects that do real, tangible stuff, and introduce our sample application.

Page 3 of 9

Previous Page

Next Page