What is business logic for laypeople

Thomas Reppa

In order to use the Model-View-Controller design pattern (MVC) successfully in Flex applications, the developer can fall back on many frameworks. This includes PureMVC, which, thanks to its language independence and great flexibility, also promises the development of complex applications - if the developer has accepted the high entry hurdle for PureMVC.

The Flash platform has seen rapid development in recent years. With the Flex framework and ActionScript 3, Adobe has made the leap in the direction of Rich Internet Applications (RIAs). While web designers used Flash almost exclusively for the development of multimedia advertising materials such as banners and microsites in the past, it can be used in conjunction with Flex and Adobe's AIR (Adobe Integrated Runtime) for complex browser and desktop solutions.

For many Flash developers, the topic of application architecture now plays a major role; it can determine the success or failure of a project. A tried and tested approach to structuring an application is the Model-View-Controller design pattern (MVC), which separates the application into three independent logic layers:

  • Model: The data layer holds all of the application's underlying data. These can be texts as well as the states of individual control elements.
  • View: The presentation layer contains all elements presented to the user. In addition to the visualization of text, images and sound, this also includes the display of input elements such as buttons and text fields.
  • Controller: The control layer is responsible for the business logic of the application. It manipulates the data layer through user input or controls cross-application tasks.

Typically, every Flex application can be broken down into layers. However, if they are not set up separately from one another, maintenance and further development can quickly become confusing, time-consuming and expensive. Due to the simple use of the Flex components and the resulting increased productivity, the temptation is great to neglect the separation of the program logic and "go ahead and develop".

Flex offers good prerequisites for separating the three layers from one another. On the one hand, this is due to the extensive component library, which is suitable for creating the views. On the other hand, Flex's own "data binding" can directly link the components with the data layer and automate the filling or updating of the presentation layer. A simplified separation of the application logic could look like in Figure 1 with Flex.

  1. The user triggers an action in the view (for example button click).
  2. The controller picks up the action and converts it into a manipulation of the data layer.
  3. The data binding updates the view.

In order to use the MVC pattern successfully in applications, the developer can fall back on a number of MVC frameworks. These include Cairngorm, Mate and PureMVC. While Cairngorm [1] is most popular because of its age and as a de facto Adobe framework, PureMVC can be seen as an interesting alternative for MVC-based Flex development.

Due to its language independence, PureMVC clearly stands out from Cairngorm. It does not use any Flex or Flash-specific classes and can therefore be ported to Java, C #, Objective-C, Ruby and a few other languages. Once the framework has been learned, programs for Silverlight, iPhone or other platforms can be written according to a familiar pattern. Another advantage is the relatively large scope for communication between the individual logic layers in PureMVC. If you use Flex / ActionScript, this means that communication from the model to the view does not necessarily have to take place with data binding, as is the case with Cairngorm, for example. Due to the freedom for the developer, the entry hurdle for PureMVC is to be assessed as higher than for other frameworks. For this purpose, PureMVC is expanding its area of ​​application to the development of complex applications thanks to its flexibility.

Why PureMVC?

The initial effort for a PureMVC application is significantly higher than for one without PureMVC. This is mainly due to the fact that the developer has to follow a certain pattern when setting up an application. As a rule, more code has to be written during development than would be the case without the framework. But when a project reaches a critical size, the additional effort is quickly put into perspective. The bottom line is that overall less time is required due to fewer corrections in the code, optimized work in the team, a clearer program structure and thus a higher quality of the result. In addition, the additional effort on which the framework is based can be compensated for by the sensible use of tools such as Ant or code templates in Eclipse.

MVC in PureMVC

MVC in PureMVC

A PureMVC application is divided into two areas. On the one hand, the MXML components (View) with the associated data models (Model). On the other hand, PureMVC, which controls the communication between MXML (originally for Magic eXtensible Markup Language) and data models. Neither the MXML components nor the data models should be aware of how they are linked by PureMVC. One of the advantages of this is that both can be reused across projects (see Figure 2).

PureMVC provides the developer with five types of classes:

  • Notification
  • Proxy (Model)
  • Mediator (View)
  • Command (controller)
  • Facade

Notifications are similar to Flash and FlexEvents, PureMVC's own message classes. They allow the developer to send and receive messages to the framework. A notification consists of a unique ID (name), an optional container for data (body) and a type for different purposes, such as assigning the data object.

The three classes proxy, mediator and command represent the model, the view and the controller of the MVC design pattern within the framework. They are called "core actors" in the terminology of the framework. They are to be understood as abstract classes (even if there is no such thing in ActionScript) that the developer can extend and use as often as required for areas of the application. The login routine of a web application would have its own and its own. The core actors' areas of responsibility are as follows:

Mediators are the interfaces between the MXML components and PureMVC. They stop ActionScript and Flex-specific events triggered by user interactions and convert them into notifications. On the other hand, mediators can receive PureMVC notifications and use them to trigger a specific action or method in the MXML component. Applying the two tasks of the mediator to the login example results in the following scenario: After the user has clicked on the login button, the flash event sends the login information "user name" and "password" to the mediator. He then converts the action into a notification. After other parts of the framework have processed the "Login" notification, the mediator is informed of the success of the login process. It then forwards the result back to the login component (see Figure 3).

Commands are the controlling element in PureMVC that implements the application's business logic. They can be linked to one or more notifications (command mapping). If a core actor like the one in the example sends a notification to PureMVC, it executes the associated one. It doesn't matter who sent the message. For example, it is possible to start a login routine from different parts of the program without having to think about what will happen to it in advance. Only the command decides what happens to the login data and who takes care of further processing (see Figure 4).

PureMVC knows two different command types: "SimpleCommands" and "MacroCommands". The latter are used to link the former and are required when a number of independent subroutines are to be executed. It should also be noted that commands are stateless. This means that they must be instantiated while the associated notification is being sent at runtime. Once the command has been processed, it is deleted from the memory again.

Proxies are at PureMVC the link between the framework and data objects, the so-called Value Objects (VOs). The proxy can either change or read the VOs directly or it can access external data sources such as web services and local databases. It should be noted that they usually do not contain any program logic, but can only be used to save the data while the program is running. Since proxies, unlike mediators and commands, cannot react to notifications from the framework, the commands usually address them directly.

In our login example, the method would call and send a request with the login data to a remote service. After the server has processed the data, it receives the result back (see Figure 5).

The saves the user data received in a value object and sends the notification with the name to PureMVC or to the person who can process the result further (see Figure 6).

In order to be able to use PureMVC, each core actor must first be registered for its area of ​​validity via the Facade class. The following methods are available for this:

  • ,
  • and
  • .

If the developer would like to remove a specific core actor, he can use the following methods:

  • ,
  • and
  • .

The registration and deregistration of the core actors is not the only place in PureMVC where the facade hides complexity from the developer. Furthermore, the methods of the facade trigger the sending and assignment of notifications, the command mapping and the initialization of the framework, and they are internally delegated to the right place in the framework. The facade is the communication interface of the PureMVC framework. On the one hand, it can be addressed by all mediators, proxies and commands via the core actor property. On the other hand, it offers simple access methods to all functions of the framework without necessarily requiring an understanding of the framework logic.

Sample application

Next Steps

Although the theoretical understanding is an important basis for the use of the framework, the functionality can usually only be understood in the practical application. Familiarizing yourself with the framework using the login example described would therefore be a sensible next step.

The complete source code including explanatory communication diagrams can be downloaded here. To get you started with the specific code example, the next section illustrates the PureMVC initialization process.

First of all, the PureMVC class library has to be integrated either as a compiled SWC file or directly as an AS3 class package in the library folder (usually called "libs") of the Flex project. The advantage of an integration as an AS3 class is that the source code of the framework can be browsed. Both variants can be downloaded from this link. The standard PureMVC structure is then created in the "src" folder of the project as shown in Figure 7.

The package "controller" contains all commands, the package "model" all proxies, and the sub-package "vo" contains all value objects. Mediators and Flex components are located in the "view" package and in the "components" sub-package. Once the package structure has been created and PureMVC is linked to the project, the initialization of the framework can begin.

To start with, you expand the class to become a class. Please note that this is a singleton, a class with only one instance. They can be accessed through the method.

The next step is to create the notification required by the application. Although initially only the "startup" notification exists, in the course of the development of a project numerous new notifications are added, which can either be written directly into the as static constants or transferred to an extra class.

After the instantiation, PureMVC runs through a series of internal routines. Among other things, calling the method in which previously created commands can be linked to the associated notifications. In the simplest case, you connect the notification with the.

public class ApplicationFacade extends Facade implements IFacade
{

/*
* 2. NOTIFICATION IDs
*/
public static const STARTUP: String = "startup";

/*
* 1. Singleton implementation
*/
public static function getInstance (): ApplicationFacade
{
if (instance == null)
instance = new ApplicationFacade ();
return instance as ApplicationFacade;
}


/*
* 3. Link notification IDs with commands (command mapping)
*/
override protected function initializeController (): void
{
super.initializeController ();
registerCommand (STARTUP, StartupCommand);

}

}

Before this and the notification are linked to the method, the command must first be created in the "controller" package. It usually registers application proxies and mediators.

public class StartupCommand extends SimpleCommand implements ICommand
{

override public function execute (notification: INotification): void
{
/*
* The reference to the main component of the application (PMVC_Login)
* is stored within the body of the notification
*/
var appview: PMVC_Login = notification.getBody () as PMVC_Login;

/*
* 1a. Register mediators
*/
facade.registerMediator (new ApplicationMediator (appview));

/*
* 1b. Register proxies
*/
facade.registerProxy (new ConfigProxy ());

/*
* 2. Loading configuration
*/
var proxy: ConfigProxy = facade.retrieveProxy (ConfigProxy.NAME) as
ConfigProxy;
proxy.loadConfig ();

}
}
}

From here, for example, configuration files can be loaded via a proxy. If this and that has been created, the "startup" notification must be sent from the main Flex component following the event.

It should be noted that the Flex component of the notification transfers a reference of itself so that it can be passed on to, for example, within the.

xmlns: mx = "http://www.adobe.com/2006/mxml"
creationComplete = "init ();">

<mx:Script >

private function init (): void
{
// Initialization of the facade / PMVC Framework ()
var facade: ApplicationFacade = ApplicationFacade.getInstance ();

// Send startup notification
facade.sendNotification (ApplicationFacade.STARTUP, this);
}
</mx:Script>

</mx:Application>

Conclusion

Conclusion

Even if the entry into PureMVC seems daunting, especially for beginners, thanks to the good documentation and the extremely helpful community, you can find your way around after a relatively short time. This is not least due to the fact that PureMVC inventor Cliff Hall looks after them with great commitment to this day.

Although PureMVC is ideally suited for the development of larger projects with several hundred classes, entering into projects of this size with PureMVC should be treated with caution. It is therefore advisable to develop a smaller application the size of a microsite for the first use in order to get to know the framework and at the same time to keep the risk and complexity low. If you develop in a team, it must be ensured that everyone involved has the same understanding of proxies, mediators and commands.

Once the first hurdle has been overcome and the first project successfully completed, the development with PureMVC can be effective and at the same time be a lot of fun. The great flexibility of the framework allows almost any kind of application including the development of games. Another use is the PureMVC multicore variant, which is only available for Flex and ActionScript 3. With it you can run several PureMVC cores or facades in parallel and link them to one another via a shell.

Thomas Reppa
is developer and trainer for Rich Internet Applications and managing director of REPPA.NET. He also looks after the Adobe Flex User Group Munich.

Links & literature

  1. Kai King; What's missing - design and architecture of RIAs with Flex; iX 4/2009, p. 152
  2. PureMVC