Mediator to Proxy coupling

[dbasch]

A quick question for everyone. There seem to be two ways for Mediators to interact with Proxies in PureMVC

1) A Mediator responds to a Notification and uses the body of the Notification within the Mediators view level logic.

2) A Mediator responds to a Notification and calls a public function of a Proxy. The functions return value is used within the Mediators view level logic.

Which is better? It seems to me that method #1 couples the view to the model pretty heavily. Is it simply up to the developer depending on the level of layer decoupling that is desired?

Thanks,
Derek Basch

[dbasch]

I think I got my head around this a bit more now. I was reading the prior version of the Implementation document and it didn't cover this topic as well and the more recent version. I think this snippet says it all:

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.

I do often see Mediators calling functions of Proxies in the example code. However, it looks like they are one way calls and the Proxy functions are not expected to return a value, but rather, to set a value on their encapsulating Proxy that is later retrieved.

[puremvc]

You got it. It's an easy way for the view to get the data back into the model without having to write a Command (increasing complexity) to do a simple set or get.

But as soon as you start doing all sorts of interaction to massage that data in one or more Proxies in a Mediator, it's time to move that out to a Command and dub it Business Logic.

-=Cliff>

[dbasch]

Thanks for the reply Cliff. Keep up the good work

[galeto]

I had the exact same question!

I'm not a MVC expert but I really though going to proxies directly from mediators was not good.

That's almost only leaving the startup/component registering/shutdown jobs to the controller isn't it?

I have the feeling that the controller has a really thin job in pureMVC, tell me if I'm wrong.

Alex

[trilec]

Hi Alex,
I feel this depends on the application, the Mediator(controller) has a crucial job of managing UI components, its dealings with the proxy are determined by its need for data storage and manipulation.This coupling can be tight or loose depending on the granularity you may require in your application.
I tend to bias slightly tighter connections due to my C++ optimization fetish's, but through my study off MVC patterns I realize the value of a looser coupling and try to design accordingly.

I find when starting my first design phase, granularity starts to become more apparent.

• Many UI components? (will it be modular and How should this breakdown?) (Commands? mediators?)
• large amount of data?  (startupManager?, How many proxies?)
• need for VO's? (whats getting passed around the application?)
• Login ? (yet another proxy? or VO [value object])
• Preloading?

etc.

T

[galeto]

I had the exact same question!

I'm not a MVC expert but I really though going to proxies directly from mediators was not good.

That's almost only leaving the startup/component registering/shutdown jobs to the controller isn't it?

I have the feeling that the controller has a really thin job in pureMVC, tell me if I'm wrong.

Alex

Any pureMVC staff manager want to discuss about that?

[puremvc]

Reading the Best Practices document will help to illuminate the role of Commands. But yes, the need for many Command classes has been greatly reduced by the collaboration allowed between Mediator and Proxy.

-=Cliff>