MACROMEDIA FLASH MX 2004-USING ACTIONSCRIPT IN FLASH Use Manual page 126

Using the MVC design pattern
Many Flash developers implement the MVC (model, view, controller) design pattern when they
build applications to separate the logic and data of the application from the user interface. This
section defines how the design pattern works, and provides an overview of how and why you
might use it for your Flash applications.
The MVC design pattern is used to separate the information, output, and data processing in the
application. The application is divided into three elements: model, view, and controller; each
element handles a different part of the process.
The model This part of the MVC design pattern incorporates the data and rules of the
application. Much of the application's processing occurs in this part of the design pattern. The
model also contains any components (such as CFCs, EJBs, and web services), and the database.
Data returned is not formatted for the interface (or front end) of the application in this part of the
process. This means that the returned data can be used for different interfaces (or views).
The view This particular component of the pattern handles the front end of the application
(the interface with which the user interacts), and renders the model's contents. The interface
specifies how the model's data is presented and outputs the view for the user to use, and lets them
access or manipulate the application's data. If the model changes, the view updates to reflect those
changes by either pushing or pulling data (sending or requesting data). If you create a hybrid web
application (for example, one that includes Flash interacting with other applications on the page),
you can consider the multiple interfaces as part of the view in the design pattern. The MVC
design pattern supports handling a variety of views.
The controller
The controller handles the requirements of the model and view to process and
display data, and typically contains a lot of code. It calls any part of the model, depending on user
requests from the interface (or view), and contains code that's specific to the application. Because
this code is specific to the application, it is usually not reusable. However, the other components
in the design pattern are reusable. The controller does not process or output any data, but it takes
the request from the user and decides what part of the model or view components it needs to call,
and determines where to send the data and what formatting is applied to the returned data. The
controller ensures that views have access to parts of the model data that they must display. The
controller typically transmits and responds to changes that involve the model and view.
Each part of the model is built as a self-contained component in the overall process. If you change
one part of the model (for example, you might rework the interface), it reduces problems because
the other parts of the process do not usually need modification. If your design pattern is created
correctly, you can change the view without reworking the model or controller. If your application
does not use MVC, making changes anywhere can cause a rippling effect across all your code,
which requires many more changes than if you were using a specific design pattern.
126 Chapter 3: Using Best Practices