Tag Archives: flex

Flex – Cairngorm Microarchitecture

by on June 20, 2007 in Report

What is Cairngorm?

Adobe Consulting Group has defined an architectural framework for Flex application, named "Cairngorm". The framework has borrowed quite a bit of design patterns from GOF and J2EE. Its goal is to help us to layout the groundwork for complicated RIA. It is interesting to see how those patterns work together in a seamless way. The framework not only cleans up our code, but it also decouples our components. The result is very neat and elegant!

flexarch.JPG

Lets go through some interesting points for this microarchitecture. I assume you already read this excellent 6 parts articles from Steven Webster.

Encapsulate your Flex component and make it no dependency to the Cairngorm framework to promote high reusability

  • To do a better encapsulation – input (VO) and output (event) are non-Cairngorm object.
  • Component internally use VO to bind to its controls and external link VO from ModelLocator to it. So, whenever the VO in ModelLocator be changed by Command, the components’ controls that link to it will be updated.
  • User gesture is first captured by the component via event listener and then re-dispatched as custom event and bubbled up. Have the View that uses the component to capture the custom event and re-dispatch again as one type of CairngormEvent with VO loaded. In Cairngorm 2.2, you simple can call the "dispatch()" method from the CairngormEvent. Then, the FrontController can take care the rest. The CairngormEvent dispatched should be non-bubbled and cancellable.

View is the place for layout the controls and interact with Cairgnorm objects (normally it is non-reusable)

  • View can set up control with VO from ModelLocator and capture custom event from control and re-dispatch it as a type of CairngormEvent.
  • View contains state definition that is explicitly binding to the ModelLocator where it contains what state the View should be. The code below indicates that when the search_state is changed, the searchState() method will be invoked and alter the state of the View.

[code]]czoxMTc6XCImbHQ7bXg6QmluZGluZyBzb3VyY2U9JnF1b3Q7e01vZGVsTG9jYXRvci5nZXRJbnN0YW5jZSgpLnNlYXJjaF9zdGF0ZX17WyYqJl19JnF1b3Q7IGRlc3RpbmF0aW9uPSZxdW90O3NlYXJjaFN0YXRlJnF1b3Q7IC8mZ3Q7XCI7e1smKiZdfQ==[[/code]

Command should be the one that changes the model

  • FrontController is a registry that associates Event with Command. This mapping can be M:1.
  • Consider ModelLocator is a mediator for Views to interact one another via changing the model.
  • Delegate may intercept the response via registered its result and fault handler. The goal is to hide the detail from remote call. Therefore, it is good practice to convert XML to VO (via Factory) before invoking Command’s result and fault handler.

[code]]czoxOTU6XCI8Zm9udCBzaXplPVwiMlwiPnZhciB0b2tlbjpBc3luY1Rva2VuID0gc2VydmljZS5zZW5kKHBhcmFtcyk7IHZhciByZXNwb3tbJiomXX1uZGVyOm14LnJwYy5SZXNwb25kZXIgPSBuZXcgbXgucnBjLlJlc3BvbmRlcihzZWFyY2hCb29rc19vblJlc3VsdCwgc2VhcmNoQm9ve1smKiZdfWtzX29uRmF1bHQpOyB0b2tlbi5hZGRSZXNwb25kZXIocmVzcG9uZGVyKTs8L2ZvbnQ+XCI7e1smKiZdfQ==[[/code]

How to unit test Cairgnorm-enabled project

  • VO, Service, FrontController, Event and ModelLocator are simple classes that are not subject to test.
  • Command can be tested with Mock Delegate
  • Model can be tested if it contains logic
  • Factory can be tested if it contains parsing logic.
  • Delegate can be tested with Mock Service (but a bit tricky as how to write a mock service)
  • Control can be tested via addListener for the custom event thrown.

References

Update

Recently, I have heard that PureMVC provides a clean framework than cairngorm as cairgnorm uses a lot of singleton framework class. I haven’t got a chance to look into it. Be sure will keep you update if I find it interesting.

 

Leave a comment • Continue Reading →

Flex Architecture – MVCS

by on May 24, 2007 in Report

I have come across an excellent article from Joe Berkovitz that talks about a “right” way to architect your application. I like this article a lot. It gives me a good refresh of what I have learnt in these years. I decide to spend a little time to go over some of the key points from this article.

Isolation and encapsulation are the keys. Isolating concerns opens the door to accommodating change, because it puts boundaries on the ripple effects of changes within the code. Isolation makes modular development and testing easy. Isolation makes it easy to have different people work on different pieces. Finally, isolation makes it easier to envision ways of improving the user experience that are generalized and powerful.

The first rule I learnt in component design is “Reduce coupling and increase cohesion”. The goal of this is to reduce the amount of interactions among components and in turn promote reusability and reduce complexity. This concept proven to be useful in my career life. The tricky part of it is to draw a line around a component and provide a clear responsibilities (ie. via interface) and interactions of it (ie. communication). A good architect can make it very clean and simple whereas a novice designer cannot make a component reusable without associated with different dependencies. In this article, the author focuses on the design in UI, but the rules apply to all aspects of design. A term “MVCS” is mentioned that adds “Services” to the common known MVC pattern. Service is responsible to encapsulate the communication with the external world. Here is the diagram of the MVCS:

MVCS

In MVCS, Model captures the state of the application. It doesn’t know any of the non-Model classes and it carries no intelligence (ie. no function but read/write for properties). According to the author:

In general, avoid functions, since they introduce more complexity, and stray interactions with non-Model objects can creep in. Complex logic for model objects usually belongs in the Controller.

However, from what I have learnt, there are certainly logics belongs to the model classes. A domain model without any behavior is termed as “Anemic Domain Model” by Martin Fowler. “…this is an anti-pattern because it’s so contrary to the basic idea of object-oriented design; which is to combine data and process together.” When I look closer, this is the model that supports the UI but not the domain model in the server side. Is the same rule applied in this area as well? On the other hand, how the model notifies the View if its state is changed? In Flex, you can define your properties as “Bindable”. Whenever the state of the model is change, an event will be fired to notify the associated View.

View references objects in Model via data binding. Bindings are used to move data from sources that change into destinations that need to be change-aware. Besides,View captures users interaction (via event handler registration) and hands off action to Controller (via calling Controller’s function in event handler). Controller, like Session, is application-wide object that should be obtained through a static instance variable to avoid having to pass all such objects all over the application.

Controller is the center of the application. It is the place where application logic and behavior are implemented. It is the only part of the architecture that communicates with all the other parts, thus relieving the View, Model, and Service packages from needing to know too much about each other.

Service objects make up a layer of objects that handle all communication with the outside world like Web Service and Http calls. Besides, Services act as factories for Operation objects; it is actually these Operations that do the work of communication by initiating requests, handling responses, and dispatching status and completion events. Why not just do it internally rather than generate the Operation for controller to call? According to the author, it gives more flexibility. However, I don’t see such much usage of this flexibility. So, I still prefer doing simple Service’s method call… :)

 

fig_09.gif

Leave a comment • Continue Reading →