How to implement routine utility functions in puremvc

[bigTimeOperator]

Hi, often when I am building a puremvc application I'll have a set of controllers that act on a series of proxies. Often the controllers will need to access data from one proxy, use that info to access another bit of data on another proxy, etc. I find myself wanting to write static utility functions to handle some of these more routine operations that many of my controllers need. This would help me avoid a good bit ofduplicated code. For example I'm working on a video application that updates scores as the video progresses. Often I'll need to know the current active players at a particular time. This involves looking up the play in one proxy, locating play ids and then looking those up in a proxy of plays. It'd be great if I could somehow introduce a static utility class that my controllers could access .. something like this:

var curPlay:PlayVO = PlayUtils.getPlayAtTime(time:Number);

I guess my real question is how I can introduce a static class like this that still can access to the Proxies and Mediators in my application. Is it just a matter of passing in the facade to that function? I'm curious how others e have approached this.

[puremvc]

The idea of static utility methods is attractive, but leads to big classes that know too much and that too many actors have to know. It doesn't encourage the loose coupling that we strive for with OOP.

What you're seeing is a muddling of business and domain logic. From the Best Practices doc:

Commands house the Business Logic of our application; the technical implementation of the use cases our application is expected to carry out against the Domain Model. This involves coordination of the Model and View states.

The Model maintains its integrity through the use of Proxies, which house Domain Logic, and expose an API for manipulation of Data Objects. They encapsulate all access to the data model whether it is in the client or the server, so that to the rest of the application all that is relevant is whether the data can be accessed synchronously or asynchronously.

What this breaks down to is that you may simply want to move more of the logic that has to do with model relationships into the proxies themselves. It is perfectly fine for one Proxy to retrieve and collaborate with another. So if you're doing a lot of laborious assembly of stuff from various related Proxies in Commands, you may instead do that assembly inside your Proxies. The Proxies should encapsulate complex relationships between the data and make it easier for the actors that collaborate with them (Mediators and Commands), obviating the need for the utility methods. 

-=Cliff>

[bigTimeOperator]

Thank you. This is good advice I am sure. So far my proxy classes have been simple collections that do little more than just pass on iterators or data objects for the controllers to parse and sort though. I will experiment with making the proxy interface more robust instead of leaving all the heavy work to the controllers.