Using the MVC design pattern

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

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. The returned data can be used for different interfaces (or views).

The view

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 the user 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), 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

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), the other parts of the process do not usually need modification, which reduces problems. 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.

An important reason to use the MVC pattern is to separate data and logic from the user interface. By separating these parts of the process, you can have several different graphical interfaces that use the same model and unformatted data. This means that you can use your application with different Flash interfaces, such as an interface for the web, one for Pocket PC, a version for cell phones, and perhaps an HTML version that doesn’t use Flash at all. Separating data from the rest of the application can greatly reduce the time it takes to develop, test, and even update more than one client interface. Similarly, adding new front ends for the same application is easier if you have an existing model to use.

Only use MVC if you build a large or complex application, such as an e‑commerce website or an e‑learning application. Using the architecture requires planning and understanding how Flash and this design pattern work. Carefully consider how the different pieces interact with each other; this typically involves testing and debugging. When you use MVC, testing and debugging are more involved and difficult than in typical Flash applications. If you build an application in which you need the additional complexity, consider using MVC to organize your work.