My second presentation at Scotch On the Rocks was Flex Client Architecture & Best Practices. The one topic in the presentation which gained most attention was probably PresentationModels. I would say there is not really any magic to how to use PresentationModels, but it is more down to what kind of logic you put there and how it relates to your services. The PresentationModel pattern is also independent of any framework you would put on top of Flex.
If you have an interest in presentation patterns, I would recommend to look at Paul Williams great presentation pattern blog series. He also has a series covering how to unit test the different patterns, which most developers should find interesting.
Hi Borre,
really interesting slides:) I like presentation model approach and I have a question regarding this. How presentation model actually relates to model locator? Should it be instantiated within model locator?
Tomek
Pingback: Tips og Triks Til Trivsel med Flex : her er mitt arbeid
Borre,
how would you handle loading and parsing data? What I have done now is create a result/handler function in the PM. I pass on a reference to these functions inside the event that triggers a command. The command uses a delegate to load the data. Question: should the delegate parse the data, and how does it know what is the domain model the data should be saved to?
One option would be to pass a reference to the domain model in the event that triggers the command:
loadDataEvent(faultHandler, resultHandler, domainModel).dispatch()
There seem a lot of different approaches out there when it comes to which class should be responsible for what in a Cairngorm based application. A very standard approach would be to have the Command call the delegate, and give it a reference to a responder (IResponder), with a reference back to the model. The responder would then either do the parsing itself in the result method, or pass on the responsibility to a parser class, i would prefer the latter.
That said, I’m not a big fan of the chain of classes involved in the typical Cairngorm setup. There are multiple ways of getting around it, and I’ll cover an alternative soon.
I believe that the PresentationModel should be instantiated in the view, and not anywhere else. The ModelLocator is the “state bucket”, and should keep your domain data, not presentation logic which the PresentationModel is responsible for.