Architecture of a flex Application

Architecture of a flex Application Program

Web developers who use Flex may initially be confused about the user interface model. Although the traditional, servlet-like, request-response model will be applied in flex, there is a better method. Because of the "[binding]" label in the ActionScript language, you can bind your view to the model data, so that the model changes will automatically affect the view. The mini-architecture of cairngorm makes this method formal, and it is also a very good starting point for developers who want to understand how to "let them work together. In this articleArticleI will describe how variable binding, feature-driven development and carigorm work together in notetag

Here is the possible architecture of a typical flex application:

Domain)
· Group all classes of the domain model. In notetag, it contains notes (records), tasks (transactions), and subscriptions (subscriptions) (subscriptions are a collection of related notes or tasks )).

Model)
· A singleton instance that can be bound to a domain model ). In notetag, modelocator stores the user's subscription list, user connection, current subscription, current record, and others.

View)
· UI components (generally mxml files, though not always ). The State-dependent UI component is bound to the instance variable of modelocator. If the data in modelocator is marked as "[Bindable]", any changes to it will cause the UI to be updated automatically. One example of notetag is notelistview, which displays the list of records in the current subscription. If the current subscription or any of its records changes, notelistview will automatically update to reflect these changes.

Controller)
· The lower structure required to execute features like event-driven commands. Examples in notetag include getsubscriptioncommand, getnotecommand, and others.

Business)
· The business logic class that completes object operations in the domain. It often calls remote services and returns results asynchronously. For most notetag business logic, the subscriptionmanager class is entry point.

Service)
· The service layer stores all classes used to call remote services (httpservice, remoteservice, and WebService. Notetag uses a factory class set to reduce the deployment of special HTTP services from components that call HTTP Services.

Most application features have some or all of the above structures. The following is a workflow of typical features:
1. View broadcasts an event.
2. The controller receives this event, maps it to the corresponding command, and runs this command.
3. The command delegates appropriate business objects to execute business logic.
4. The business object executes the business logic. One or more asynchronous calls may be made to different services, and a new event is dispatched to the command to return the result.
5. The command assigns the result to the single model.
6. All views bound to data in a single model are automatically updated.

How does it work in a specific feature? When you select a note from the Notes List (below, at the top of the screen), the note will be stored properly (blogger or typepad) load and display in the editor (see the following at the bottom of the screen ):

1. Broadcast events

When you click on the first note, notelistview assigns an event as follows:

Code: [copy to clipboard] // notelistview. mxml
Private function getselectedentry (Event: listevent): void
{
VaR selectedentry: tagbasedentry =
Tagbasedentry (currentfeed. Entries [event. rowIndex-1]);
Application. application. dispatchevent (
New getnoteevent (selectedentry. Metadata, true ));
}
2. Event Response

Because the Front Controller of notetag has registered it to listen to all command events, it will be notified when getnoteevent is assigned.

Code: [copy to clipboard] // notetagcontroller.
Public class notetagcontroller extends frontcontroller
{
Public Function notetagcontroller ()
{
Addcommand (loginevent. event_login, logincommand );
Addcommand (getnoteevent. event_get_note, getnotecommand );
Addcommand (gettaskevent. event_get_task, gettaskcommand );
Addcommand (postnoteevent. event_post_note, postnotecommand );
// More commands...
}
}
The Front Controller of cairngorm provides the basic structure for listening and responding to events by executing appropriate commands.

3. Execute Command

To obtain this note, notetag needs to call the blog server that stores the user note. The getnotecommand that implements the command interface of cairngorm is like this:

Code: [copy to clipboard] // getnotecommand.
Internal class getnotecommand extends chainedcommand
{
Public override function execute (Event: cairngormevent): void
{
VaR initialevent: getnoteevent = getnoteevent (event );

VaR subscriptionmanager: subscriptionmanager =
Modellocator. getinstance (). subscriptionmanager;

Setnexteventhandler (subscriptionmanager,
Handleloadnote,
Loadnoteevent. event_load_note,
Onsubscriptionfault,
Subscriptionfaultevent. event_subscription_fault );
Subscriptionmanager. loadnote (initialevent. Metadata );
}

Private function handleloadnote (Event: loadnoteevent): void
{
// Handle result here...
}

//...
}
(You may have discovered that getnotecommand inherits the chainedcommand-This class uses the setnexteventhandler Method for a series of asynchronous calls. In future articles, I will discuss chainedcommand in more depth and give a general description of asynchronous responder ).)

4. Execute business logic

Subscriptionmanager triggers note loading by executing a series of HTTP service calls to the tag server and blog server. When the note is loaded, subscriptionmanager will assign a loadnoteevent, which will be triggered by getnotecommand. handleloadnote (see the next one.

5. Update the Model

Getnotecommand assigns the loaded note to an appropriate data member in modellocator to respond to the event.

Code: [copy to clipboard] // getnotecommand.
Internal class getnotecommand extends chainedcommand
{
//...

Private function handleloadnote (Event: loadnoteevent): void
{
Modellocator. getinstance (). currentnote = event. Note;
}

//...
}
6. Update the view

Any view bound to the currentnote member of modellocator will be automatically updated to reflect the new data. Noteview is used to display the note component in the editor. It is a view like this:

Code: [copy to clipboard] // noteview. mxml
<Mx: vbox xmlns: MX = "http://www.adobe.com/2006/mxml"
Xmlns: view = "com. Adobe. Kiwi. notetag. View .*"
Xmlns = "*">
<Mx: SCRIPT>
<! [CDATA [
Import com. Adobe. Kiwi. notetag. model .*;
[Bindable] private VAR model: modellocator = modellocator. getinstance ();
]>
</MX: SCRIPT>

<View: noteedit id = "noteeditor" width = "100%" Height = "100%"
Note = "{model. currentnote}"/>

</MX: vbox>
All other features-publish a note, get a subscriber, and update a task-will be implemented through the same event-to-command-to-model-to-view path. Command-specific events can be distributed from multiple types of content without the need to know which view will be affected. A view can be bound to a model change without knowing where the event is dispatched. Due to loose coupling, it is easier to maintainCode.

Original article: Sort ting a flex app
Address: http://blogs.adobe.com/kiwi/2006/05/architecting_a_flex_app_1.html