A typical Flex application

Another way to look at the NoteTag architecture is in terms of the division of roles and responsibilities for a typical Flex application. Here's how these roles might break down in a typical, non-trivial Flex application:

Figure 2. Architecture of a typical Flex application

The architectural elements, clockwise from the bottom, are:

Domain

The classes that make up the domain model. In NoteTag, this includes Notes, Tasks, and Subscriptions. (A Subscription is a collection of related Notes or Tasks.)

Model

A Singleton that holds bindable instances of the domain model. In NoteTag, the ModelLocator Singleton holds the user's list of Subscriptions, the user's Connections, the current Subscription, the current Note, and so forth.

View

The UI components (generally, though not always, MXML files). The UI components that are state-dependent are bound to instance variables in the ModelLocator. Any changes to data in the ModelLocator will cause the UI to automatically update, provided that that data is marked as [Bindable]. An example in NoteTag is the NoteListView, which presents the list of Notes in the current Subscription. If the current Subscription or any of its Notes are changed, the NoteListView will automatically update to reflect the changes.

Controller

The infrastructure for implementing features as event-driven Commands. Examples in NoteTag include GetSubscriptionCommand, GetNoteCommand, and so forth.

Business

Business logic classes perform operations on Domain objects, often making calls to remote services and returning the results asynchronously. The SubscriptionManager class is the entry point for most of NoteTag's business logic.

Service

The services layer holds all classes that are used to make remote service (HTTPService, RemoteService, and WebService) calls. NoteTag uses a set of service factory classes that decouple the configuration of specific HTTP services from the components that call HTTP services.

Page 3 of 4

Previous Page

Next Page