The MVC Framework

The Foundry is based on the Model-View-Controller pattern. The Model-View-Controller (MVC) is a compound pattern (a pattern composed of multiple design patterns), commonly used to create interfaces for software applications.

MVC : a composite design pattern

The MVC design pattern consists of three participants:

  • The Model stores and manages the application state (the data) ;
  • The View is the user interface. It displays the data to the user and supports the user inputs ;
  • The Controller processes events, typically user actions, and may invoke changes in the model or trigger remote calls.
Model-View-Controller elements

Model-View-Controller elements


The Model encapsulate the data handled by the application. It acts like a local storehouse for data, and expose application state to the views. It responds to requests for information about the application state and to instructions to change this state. All application-wide data manipulation should be conducted through the Model.


The view renders the data to the user (the content of Model instances). It accesses the data through the model and specifies how the data should be rendered. Using a View, the user will be able to interact with the application and ask for application state to be modified.


The controller translates the actions, performed by the user through the views, into actions to be performed by the model (or a remote data service). In Web applications, user interactions are HTTP requests, whereas in rich internet applications, user interactions could be clicks on buttons, selections in menus, lists, datagrids, drag’n’drop actions, and so on.

A RIA approach to the MVC design pattern

RIA-enabled technologies, like Adobe Flex, are commonly considered as MVC frameworks : the client-side of the application plays the role of the View participant of the MVC. In this point-of-view, the MVC is more an architectural pattern than a design pattern. If we look deeper into the application structure, we can consider the GUI itself as an application. That is the reason why the MVC design pattern is well-suited as a basis to develop smart user interfaces.

Most of the documentation that can be found about the MVC is about Web applications. The Web applications are based on the HTTP browsing paradigm, whereas the RIA applications are closer to the client-server applications : standalone user-interfaces accessing external resources and services.

A RIA approach of the MVC design pattern should care of several differences :

  • the RIA concept breaks the standard request-response browsing paradigm,
  • in RIA applications, the back-end services are strictly considered as external resources, not as parts of the Model,
  • a RIA should be considered as a standalone, autonomous component, that means the RIA application itself shoud encapsulate the three participants of the MVC,
  • some of the design-patterns commonly used in cunjunction with MVC (RequestDispatcher, FrontController, DispatcherView…) should be removed from the conceptual model or adapted to the specific case of the development of rich-internet applications.

ActionScript Foundry

The ActionScript Foundry is a lightweight MVC framework dedicated to the development of rich internet applications using the open source Adobe Flex SDK.

“Lightweight” means there are a few ActionScript classes involved in the MVC framework itself, they all can be found in the “Foundry” package, and are all intended to handle some responsibilities of the three participants of the MVC model.

To get started with the ActionScript Foundry MVC, read this chapter or jump to the tutorial : “ActionScript Foundry : a beginner’s guide“.


The Model part of the MVC is represented in the Foundry by a single class : AbstractModel. This class is an implementation of the IObservable (also known as Subject) part of the Observer pattern (see an illustration of the Observer pattern in Java). The role of an Observable instance is to relay changes to the Observer instances (here, the views) using a notification mechanism.

For more information about AbstractModel, consult the API documentation.


The View participant of the MVC is depicted in the Foundry by two elements : the interface IView, and the ViewHelper class. Each View will be splitted in two classes :

  • an IView implementation: responsible for the layout part (commonly using MXML elements),
  • a ViewHelper : dedicated to the management of the view’s micro-logic.
View and ViewHelper as the View participant of the MVC paradigm.

View and ViewHelper as the View participant of the MVC paradigm.

Using separate classes allows loose coupling between the data gathering logic and the formatting logic of a view. It allows also to reuse a ViewHelper implementation for multiple views if needed, and avoids troubles while using complex inheritance diagrams.

ViewHelper implements IObserver interface, the Observer part of the Observer pattern. This implementation allows the ViewHelper to listen to Model changes and to pass them to the view (using the Flex SDK binding mechanism, for example).

For convenience reasons, all the containers defined by the Flex SDK have been extended and implement the IView interface : VBoxView, HBoxView, CanvasView and so on.

A common mistake is to use the View/Viewhelper pattern for low level components, the ActionScript Foundry has a Widget/WidgetManager for this purpose. Keep in mind to use view for top level component / Screen.  In fact a specific View ( e.g : CustomerManagmentView ) will not have to be implemented more than once.


The Controller participant is represented in the Foundry by the AbstractController class. As the main application entry point, one of its responsibilities is to initialize the Model and BusinessDelegate instances (see Remote procedure call for more information about the BusinessDelegate class).

As the Controller participant handles interactions, its surface (its number of members) tends to grow quickly. To avoid this, the Foundry provides an AbstractSubController class, than can be accessed through the main controller of the application, and to insure the “Single Responsibility” rule of the software development.

Previous Step

Next Step

Saturday, November 15th, 2008 No Comments by Jeff Mathiot