First glance at Cairngorm microarchitecture ~

It took me a long time to finish reading Steven Webster's introduction to the cairngorm microframework. To sum up, there are three most impressive parts,
1. The globally unique ModelLocator and DataBinding simplifies the management of the client model (or state) and the update of the view, which can avoid the pain of updating the view by hard coding and greatly inconvenient and costly maintenance, this requires rational design of various view compomnent to support full binding;
2. In addition to the event mechanism (a global event management object), FrontController decouples user gesture's direct calls to specific actions (or commands), which also facilitates the clear division of use cases, the event distributed by user gesture says that if you want to do something (you don't need to know how to do it), frontcontroller will assign specific commands to do things;
3. ServiceLocator and Command (or we should say that Command and ServiceLocator) Remove the coupling between the command implementation and the underlying service. In this way, the command only needs to borrow serviceLocator (indirect borrow, with a layer of BusinessDelegate in the middle) to implement the required functions, specifically through the Service (HttpService, WebService, RemoteObject) implemented by servicelocator, after the command interacts with the server (successful and failed processing) updating the client state, that is, ModelLocator, will naturally trigger the update of the view (1)
Even if you do not need the cairngorm microframework, many of the best practices can be used, such as the above three points.

Cairngorm development process and debugging points
Adding a New Feature to a Cairngorm Application

When you add a new feature to a Cairngorm application, it is as simple as the following process:

1. Register an event and command with the Front Controller using addCommand ().
2.

Implement a new command as follows:
1. Implement the execute () method to do the work.
2.

Implement the onResult () method to handle any results from the server:
1. Any results are used to update the Model Locator.
2. The Model Locator automatically updates the view.
3. Add any new service cballs that the Command requires for the Business Delegate.
4. If these service callrequire new services, add them to the Service Locator.

Debugging a Cairngorm Application

Furthermore, debugging a Cairngorm application follows the same predictable steps. If a desired feature doesn't perform in response to a user gesture, the debug cycle is always the same:

1. Check whether the event is registered with the Front Controller.
2. Check whether the execute () method is called on the command by the Controller.
3. Check that the appropriate delegate methods are called.
4. Check that the onResult () method is called in the command.
5. Check that the model is updated in the Model Locator.

With these five steps, it's painless to isolate a problem in an application and fix it current PERTChart control development
Current problems of pertchart and preparation for reconstruction
Many problems are associated.
1. The components of each view are not fully bound (this will lead to additional development responsibility)
2. The processing of user gesture directly calls specific actions and distributes them in various codes.
3. It has a globally unique client DataModel, but is responsible for too many tasks.
4. service calling is also handled in specific details.
5. Application. application is used as the global event management object.
It can be said that pertchart is not widely used, but its implementation functions (and for future) and interaction are quite complete.

The specific refactoring Analysis of things may be as follows:
1. There may be a lot of work, and most of the view code in each area will be concentrated in the related component.
2. The cairngorm method is used to process user gesture.
3. Distribute the processed datamodel to each command (Specific Actions)
Both 4 and 5 Use cairngorm, which is easier
6. Another problem with pertchart is the forced synchronization of interaction with the server.
Refactoring may enable pertchart to adopt more cairngorm practices or directly adopt the cairngorm framework.

~ Although a variety of development tools or platforms can be learned and applied, it will always have their own characteristics. It will be much better to learn more about it. In terms of Flex application development, cairngorm can be used to understand the practice model it advocates (which has its own characteristics). This way, we can discard the development methods that give it the development habits of other platforms and adopt them more suitable!