Organizing files and storing code

After you decide on a protocol for transferring data, you must consider how to organize your SWF files, their assets, and ActionScript. How you organize and execute your application depends greatly on its design, size, and requirements. There are guidelines to help your overall success. The following are some of the primary things you must consider before you start:

• Do you divide the SWF file into multiple SWF files, and, if so, how should they interact?
• What assets can you share across SWF files?
• What files do you dynamically load?
• How and where do you store ActionScript?

When you develop an application, try to store your server-side code and files in a logical directory structure, similar to those in an ActionScript 2.0 package. Try to arrange your code this way to keep it well organized and reduce the risk of the code being overwritten.

For larger applications, encapsulate client-server communication and services in classes. When you use classes, you benefit in the following ways:

• You can reuse the code in more than one SWF file.
• You can edit code in a central place, and update all SWF files by republishing them.
• You can create a single API that can manipulate different UI elements or other assets that perform similar functions.

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.

There are other reasons why MVC is valuable for some applications. An important reason to use the 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. Perhaps the application has a Flash 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.

RSS feed | Send me an e-mail when comments are added to this page | Comment Report

Current page: http://livedocs.adobe.com/flash/mx2004/main_7_2/00000888.html

Add Comment