Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: PureMVC proxy/model singleton vs. Cairngorm ModelLocator?  (Read 14488 times)
pebanfield
Full Member
***
Posts: 33


View Profile Email
« on: October 03, 2008, 02:25:02 »

Hello -

I am interested in building a project with Pure MVC. I have built several projects with Cairngorm which I find to be architecturally similar in some respects. My question pertains to the general strategy for the data model in PureMVC.

In Cairngorm I have been using the ModelLocator singleton as a composite for the application model. As such I find this practice helpful as it is declarative and provides a centralized overview of the application domain model.

In contrast the Pure MVC framework does not appear to have a single model singleton defining model data. Instead the model singleton allows for proxy objects to be registered via the facade. Are there any best practices regarding the structure and registering of model logic? The examples provided are small and do not address a strategy for scaling application model logic.

How, for example, would I store and access something like application configuration data in Pure MVC? In the RSS reader sample a FeedVO is utilized. Suppose I wanted to cache a collection of these on the client for a history feature. Where would these go?  Can anyone share/shed light on this subject? Thanks!

Peter
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: October 03, 2008, 09:31:57 »

The ModelLocator in Cairngorm is mightily attractive at first, but in big projects can get out of control quickly as people hang stuff on it like kids decorating a Christmas tree. And the view becomes deeply tied to the ModelLocator as you sprinkle references to it in bindings throughout the view hierarchy. That makes it really tough to reuse view components without that ModelLocator. It also makes it hard to refactor the model without affecting the view components.

In PureMVC the idea was to insulate the view components from the model implementation, in fact from the entire MVC apparatus. The Mediator creates this insulating layer.

So rather than bind to the items on a globally available singleton, instead the framework shuttles data from the model tier to the view tier using notifications. This is exactly what happens with bindings only its more generic and portable to other platforms that don't have binding.

Your model then is expressable however you like. You can create a single monolithic proxy with all your app's data if you like but everything is more managable when you break it down to an appropriate granularity.

If you have a few application preferences, you might place them on a Value Object, register a PrefsProxy to control access to it, and handle saving it. You might look at the AIR utility DesktopCitizen for how to do that. It remembers your window placement and state when you shut down your app.

For a large model, you still decompose it into objects, it doesn't matter how many there are. Proxies can hold as much or as little or any kind of data you like.

You mentioned how to cache. You might give your Proxy that needs to cache its retrieved objects an ArrayCollection as a data object. Give it an async method like retrieveObject(objid:String):void.
This method would search the arraycollection for the object and if found send off a MyProxy.RETRIEVED notification 

Otherwise it would call the service and on result, add the retrieved object to the collection, and send the same notification. Caching proxies are easy.

-=Cliff>
Logged
pebanfield
Full Member
***
Posts: 33


View Profile Email
« Reply #2 on: October 04, 2008, 02:48:14 »

Hi Cliff -

Thanks for the thoughtful response. I agree about the tendency for ModelLocator to get disorganized. Things have also tended to be complicated when I've used the model to store state data, e.g. active elements, state flags, etc. This state data is not really part of the domain model, but still needs to be stored somehow. Perhaps I should be moving this data to the Mediator, but this is problematic for persisting state across sessions. I'm still looking to improve my approach here.

As I mentioned I've tried to impose some order by structuring a composite model. This model contains references to various typed data objects that are intuitively named and structured at the cost of being tightly coupled with a specific view. In this sense ModelLocator serves as a sort of dtd for deserialized objects, but there is a price to pay for this.

I suppose I should be looking at package structure to provide the overview. But I'm not happy with FlexBuilder outline view for package exploration. Here is one place I feel Visual Studio is a better IDE with class view.

I think I will try to embrace the Pure MVC approach fully at first and see how much I miss the dtd. Thanks again.

Peter
Logged
Pages: [1]
Print