QUESTION: From 'PureMVC Argument' by Jonathan Rowny So me and the other people in my team got in a small argument over the proper use of PureMVC's mediators. We've read in various blogs that it is not a good practice to call a Proxy directly from a mediator. If you're going to call a proxy, it needs to be done from a command.
In this particular case, we're asking for the proxy to refresh some data. That's it... one call. someProxy.refresh(). The refresh will send it's notification and our mediator will update. So one of my coworkers wanted to register a command that called someProxy.refresh() and then send a notification from the mediator. If there was some business logic that needed to happen, I'd be all for it! But there isn't, we're just refreshing an array collection. So someone please tell me why should I register a command to call a proxy in this case?
ANSWER:
From "Best Practices and Implmentation Idioms ": Coupling of Mediators to Proxies and other MediatorsSince the View is ultimately charged with representing the data model in a graphical, interactive way, a relatively tight one-way coupling to the application’s Proxies is to be expected. The View must know about the Model, but the Model has no need to know any aspect of the View.
Mediators may freely retrieve Proxies from the Model, and read or manipulate the Data Object via any API exposed by the Proxy. However, doing the work in a Command will loosen the coupling between the View and the Model.
Jonathan's complaint is justified. In this case, it is increased complexity and not called for. The relationship between the Mediator and Proxy is established and accepted within the framework best practices. The real benefit of the Mediator is that it decouples the View Components from knowledge of the Model and visa versa, which is where spaghetti code begins. The need to decouple Mediators from Proxies is minimal, but the need to keep business logic in Commands is more defensible. If there are more than 2 lines of code involved and those same lines need to be executed by multiple Mediators, then pushing those two lines into a Command and replacing them with a single line to send the Notification *might* be justified if it reduces the number of actors that the various Mediators need to know by placing the collaboration responsibility on a single Command. If those 2 lines ever need to change, at least it's in one place. However, other requirements pressures in your app, such as the extra cycles to do the Notification processing and instantiate the Command can effect such a decision in certain problem domains such as 3D, Gaming, Audio, Video or Image processing. -=Cliff> |
