Adobe Flash Professional CS3 - Manual (Page 484)

FLASH CS3
User Guide
478
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 appli-
cation. 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.
Creating secure applications
Dishonest users might try to hack your application, whether you build a small portal site where users can log in and
read articles or a large e-commerce store. For this reason, consider the following steps to secure your application.
• Post data to HTTPS for data that needs to be secured. Encrypt values in Flash before sending them to a remote
server to be processed.
Important: Never store any information or code in a SWF file that you don't want users to see. It is easy to disassemble
SWF files and view their contents using third-party software.
• Add a cross-domain policy, which prevents unauthorized domains from accessing your assets.