Introduction to Robotlegs Architecture
Application architecture is most important part for large scale enterprise application. You will get some important ideas about architecture from a small article on Application Architecture, which cover usage of application architecture and basic overview about PureMVC framework.
Sometime might be you feel that application’s same result will achieve by using MXML file without using such architecture. While probably it’s true for the small application, but keep in mind that a large scale application with a framework, will allows us to effectively communicate concepts and understands a code base quicker than an application without any design pattern and practice. In this article we are going to discuss about Robotlegs framework. So first lets start with what is Robotlegs.
Robotlegs is a great architectural framework for developing Flash, Flex, and AIR applications. It works for both Flash and Flex projects. Robotlegs is a mechanism for wiring your objects together. Robotlegs is a set of modular utilities and interfaces that provide tools to ease these communication tasks, reduce repetitive coding tasks, and manage dependency injection within your application.
The framework provides a default implementation based on MVC meta-design pattern. Robotlegs provides a prescriptive implementation of Model, View, Controller and Services (MVCS) implementation to get you start. If you have experience with PureMVC then you will quickly recognize the use of Mediators and Commands in Robotlegs framework MVCS design pattern. Robotlegs is a set of modular utilities and interfaces that provide tools to ease these communication tasks, reduce repetitive coding tasks, and manage dependency injection mechanism within your application.
You will get more idea from the Official Robotlegs MVCS Diagram:
Basic Structure of Robotlegs Application
A typical Robotlegs application is compose of several parts as:
1. Context
2. Views & Mediators
3. Controller & Commands
4. Model
5. Services
Context
Context is the heart of Robotlegs implementation. It’s bootstrapping mechanism that initializes dependency injection and the various core utilities that Robotlegs uses. The context provides a central event bus and takes care of its own startup and shutdown. A context defines scope. Also its possible to have several context within application.
Views & Mediators
A view is another name for a user interface. Basically anything that is an interface between your application and the user can be considered a view. They can should only read data from a model, not write directly to it.
The mediator’s job is to quite literally ‘mediate’ the view’s connection to the rest of the system. It listens to events coming from the global event dispatcher and then invokes the change on the view. It also listens to events occurring on the view itself and then alerts the rest of the system by dispatching an event on the global dispatcher.
Controller & Commands
The controller’s job is to manipulate data on the model, processing it beforehand if necessary. The controller is usually invoked by a view in response to user input. The controller never holds onto any data, it simply processes it then hands it on (usually to a model or service).
Commands are registered to a Context via that Context’s CommandMap. CommandMap is available by default in Context and Command classes. The Command class in RobotLegs contains a single execute method which is called immediately after instantiation. You use a Command class by overwriting the execute method with your own code. Commands are simple and shorted lived. Once a Command is instantiated and execute has been called its job is done. The CommandMap does not hold onto Command instances by default, they are left to the mercy of the garbage collector at this point.
Model
Model’s role is to store state information within your application. This can be thought of as a place to store data that may need to be retrieved by another part of your program. Models send event notifications when work has been performed on the data model.
Robotlegs does not enforce the use of a specific Model class; any class can be treated as a Model. However, in order to gain access to the global EventDispatcher there is an Actor class which provides a single eventDispatcher property used to dispatch events to other actors in the system.
Service
Service is use for service tier communication with external entity like Web Services, file access, or any action that takes place outside of the scope of your application for a service class. Service classes dispatch system events in response to external events.
Conceptually there are many similarities between the service and model tiers in MVCS architecture. Because of this similarity, models and services are extended from the same base Actor class.
You will get more information about Robotlegs framework from here.
Enjoy RIA .. 
