A good discussion about Flex(Mate) Architecture

I found this link is quite good, people discussed mate application architecture, such as Managers, Presentation Model, Value objects etc

http://mate.asfusion.com/forums/topic.php?id=217, here is the diagram:

http://blog.wrench.com.au/wp-content/uploads/2008/12/presentation_model_flow_diagram_mk_4d.png

Especially this part is interesting:

From this example, it seems that, in general, best practice would be to divide each big component into 6 parts

Not quite. If every view mapped right to a model entity, then perhaps, but otherwise I don’t think that it’s a good description. Let me go though the parts you list and explain them one by one, and then put them against each other.

• Model object (for example Document): This is the representation of the data in your application.
• Manager (for example DocumentManager): A manager keeps track of model objects and provides a transactional interface for working with the model. It’s not quite as simple as one manager for each kind of model object, in some situations there might be managers that don’t handle model objects at all (for example a NavigationManager), or two managers handling objects of the same kind, it depends.
• Application controller (event maps in Mate): Controllers map actions (events) to methods on managers, and wires the application together by setting up bindings between managers and views. Local event maps can be used to create subcontrollers that act as mini-applications within a larger application.
• Actions a.k.a. User Gestures (events): These represent the actions the user (or application) can perform. Actions map more or less 1:1 to methods on managers (there are exceptions where more than one method on a manager needs to be called, or methods on several managers, but these are more rare, but also not bad in any way). Actions carry any data needed to identify in which context to perform the action, and with which data (for exampe by passing along the object that should be manipulated, as well as the objects that should be passed as arguments).
• View and Presentation Model: Presentation models act as mediators between the application and the view and contain all view logic. They insulate the view from the specifics of the application by presenting a simple, view-centric interface of the model to the view. For example, if a view should display the details of an employee, instead of handing the Employee object directly to the view the presentation model presents an interface containing the properties name, phone and email. Behind the scenes the name property is created by concatenating the firstName and lastName properties of the Employee object. The view call methods on the presentation model, and the presentation model translates these method calls into actions that the application understands.

Now, what goes where?

• Model object vs. Manager: Model objects contain all the code for manipulating their own state. The manager only provides an interface for calling methods on model objects in a safe way.Many times a manager will have methods that have the same name and the same parameters as the model object. The manager may check the parameters before calling the model object, or it may register that the action has been perform (for example to provide undo-capabilities).A manager may also have methods that acts on the current item of some kind, without the caller having to have a reference to the object representing the current item — but it is still the model object that does the work.Model objects should not have a mutable interface, i.e. they should not have public methods that change their internal state. Instead any methods that change state should be hidden so that only managers can call these (you can always get around this, but it’s a conceptual kind of hiding, more like marking the methods so that it’s obvious that they should not be called willy-nilly).
• Manager vs. Presentation Model: Managers are the model, they keep track of model objects, modify them and move them around. Presentation models adapt the model for views. In some ways managers and presentation models are similar, they keep track of objects and present an interface for working with these objects — and to the view, it’s presentation model is the model. It doesn’t know anything beyond.You ask specifically why we can’t ditch the managers and do all the things managers do in our presentation models instead. One reason is that each view class has it’s own presentation model class, so there would be code duplication. Managers provide a single interface for manipulating the model, leaving no room for errors that occur when different parts of the application do the same thing slightly differently. By having a single interface we can also add side-effects to some actions/user gestures; side-effects like saving only when it is needed or keeping an undo history.
• Manager vs. Event Map: Event maps should be kept as simple as possible, essentially only mapping events to method calls, or remote calls (besides creating managers and setting up injectors). Event maps only wire things together, they should not contain any logic more complex than moving some data around and wating for the response of a remote call. Event maps should be stateless (they act the same regardless of when an even arrives) — managers, however are stateful and do what is relevant for the situation.
• Presentation Model vs. View: everything that is not display object related can go in the presentation model. The view should bind to properties and call methods on the presentation model, and it should avoid to do things like concatenating properties or filtering lists by itself. The idea is to make the view code as simple as possible, and all the view logic testable.The idea of using presentation models is to fool the view into thinking that the interface that the presentation model presents is the whole application. That way it becomes simple, reusable and it will contain so little logic that it doesn’t even need to be tested.

Advertisement