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: Model Locator pattern in PureMVC  (Read 8524 times)
carl
Newbie
*
Posts: 5


View Profile Email
« on: July 06, 2007, 11:14:14 »

I was thinking about PureMVC in terms of Cairngorm. Just trying to understand one framework by comparing it to another.

Is it correct to think about PureMVC's Model object that is hidden behind the Application Facade as being similar to Cairngorm's Model Locator pattern? Just in the sense that it is the one place to attach references to all of your models/proxies and access them in a convenient and consistent manner.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: July 07, 2007, 10:00:56 »

Hi Carl,

In the sense that the Model/ModelLocator is like a Christmas tree and we adorn it with all our cheery holiday data objects, yes the PureMVC Model is similar to the ModelLocator.

However it differs quite a bit in terms of how we actually access to the data.

In Cairngorm, typically you:
  • Define the ModelLocator class as a Singleton.
  • Add properties to it.
  • Fetch the ModelLocator Singleton at various places in the View by calling its getInstance method.
  • Bind to its properties.

Binding is something else that is very Flex/Flash-centric that was verboten to rely upon for the PureMVC implementation. In an environment that doesn't have the Flex and Flash classes, events and binding can't be counted upon being there there for you. At least not with the Flash/Flex implementations. (Think Mozilla Tamarin, or even J2ME, or maybe curl).

In PureMVC, you:
  • Define proxies to hold the data
  • Register them with the Model, typically via the Facade
  • Retrieve the Proxies elsewhere with Commands or Mediators
  • Set the data on the View Components with Mediators

Of course there's nothing to stop you from fetching the Proxies inside your View Components, and binding to their data. But that makes the View Components less portable since they now have this inherent PureMVC stuff in them.

Look at the Architecture 101 demos. All custom components have no knowledge of the PureMVC system or where their data comes from at all. This means you could carry them away and make a Cairngorm demo around them without having to remove any PureMVC framework stuff at all. Instead they expose an API to that their Mediators use to communicate with them, using public properties and Events. Internally they use binding all they wish to move data around and change their behavior based on the current data in the controls.

This is the path to reusability in View Components.
Logged
Pages: [1]
Print