архитектура flex приложений

Sometimes, the Commands need not to (or not only to) update the model, but also to act in a way that could update the User Interface. For example, imagine a PopUp Window that prompts a user to confirm the deletion of a Book. The user confirms it, so the view dispatches a DeleteBookEvent, the DeleteBookCommand actually deletes the book, but through an asynchronous operation, such as a Service call.

The way the controller can handle these events and the corresponding actions can take different forms. But, most of the time, we use yet another pattern : the Command pattern. The controller becomes a FrontController that listens to user gesture events and delegate to objects named Commands what to do. A command encapsulate the action corresponding, most of the time, to a user gesture. This is extremely powerful since it allows to easily implement some complex mechanisms such as an "undo" gesture, macros, etc...

The Controller is responsible for the logic that takes place between the View and the Model. When the user interacts with the interface, the Controller is supposed to do something (update the Model, most of the time). Again, in its simpliest form, it's a list a methods in the application's root component. But this would result in the tightest coupling we can think of between the main View and the Controller. So we need to seperate them. This, again, can be achieved with events : the views simply dispatch events, the controller listens to them and acts accordingly.

So we could, for example, encounter a Model that takes the form of a Singleton with some properties such as currentBook, typed Book (our Value Object), and bookList, typed ArrayCollection, which would, of course, consist of a list of Book objects.

So, quite often, it is implemented as a Singleton, because it is unique and might be accessed easily. Sometimes, it's scattered into several objects, and this Singleton is just a way to access these different parts. Among these objects, we find Value Objects. Just like the application server's, a Flex Value Object is a representation of a Database table record.

The Model layer is just supposed to store data, thus representing the state of the application. It has no logic, excepted maybe logic that is strictly related to data access. In its simpliest form, it's just a collection of properties declared inside the application's root tag. But this is not a good a idea because Model cannot belong to a view without becoming highly dependent to it.

This way, our views are as independent as possible from the rest of the application. They only deal with what they need to. For example, you might see a BookForm, which lets a user update a Book object with a form. Our BookForm component will only have a reference to the currentlySelectedBook, a Book-typed property in our Model (a ValueObject). The user will click on a "Save" button, which will dispatch an UpdateBookEvent. The Controller will listen to this event, do what it has to do, and update the Model's currentlySelectedBook property accordingly. Since this property is linked by DataBinding to our BookForm, it will immediatly show the updated Book.

Inside this hierarchy, communication is achieved through an implementation of the observer pattern : flash's Event mechanism. This allows communications while reducing dependencies, which is exactly what we need. Moreover, Flex provides an additional mechanism to easily update shared data between the views, which also relies on Events : DataBinding.

The View layer of the Flex MVC mainly consists of your user interface which, most of the time, is described as a hierarchy of MXML components. The application's root component represents the top of the UIComponents hierarchy. It can be either an Application object (in the case of web Flex applications), or a WindowedApplication object (for AIR). In a Modular application, it can also be a Module object designed to be loaded in a container application.

In the first part of this series, we've seen that the Flex application can be seen View layer of the RIA MVC. But the Flex application can itself be thought of as an MVC inside the web application MVC :

Before I begin, I should probably warn you dear readers : while some of you (I'm lookin at you Java guys ;) ) are quite familiar with the concepts discussed here, others may find it overly complicated for no obvious reason. The goal of this post is not to tell how a Flex application should always be built, but rather to present common solutions to common problems and how to articulate them. However, with the use of code generators, you may find out that more classes does not necessarly mean more work. But that's for another post.

The Flex application architecture as a Model View Controller (and other related concepts)

Today, we'll see how one can structure a Flex application to limit the coupling between the various layers of our application with the help of design patterns. Our goal is to apply common methodologies through best practices that favor code reuse, maintainability, legibility of code, and productivity. We won't discuss design pattern theories here, nor are we going to enter the details of their actual implementation in ActionScript. We're just here to try to grasp a picture of a Flex application architecture main concepts.

While Flex offers various ways to communicate with an application server, most of the time, for an enterprise application, the choice is easy : either a WebService object to communicate with SOAP WebServices, or a RemoteObject to communicate with any kind of service behind an AMF Gateway. This last solution provides great benefits both in terms of performance and development since it deals with ActionScript binary objects.

Among other things, this means that it has to be as independent as possible from the application server's implementation. Ideally, a Flex client should be able to switch from a service to the other as smoothly as possible. The only dependencies it needs to have is to the Service API, which, as we know, may return so-called Value Objects.

In the previous parts of this series, we've seen that a Flex client can be considered as the View layer of a RIA MVC-like architecture.

This post belongs to a four part series :

Published by david_deraedt on February 16th, 2008 in ,

Flex Architecture Fundamentals Part 3 : Designing the Flex application as a Model View Controller

Flex Architecture Fundamentals Part 3 : Designing the Flex application as a Model View Controller | David Deraedt