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: mediators and proxies  (Read 6175 times)
matthewpotato
Courseware Beta
Newbie
***
Posts: 3


View Profile Email
« on: February 05, 2008, 11:57:06 »

Are there disadvantages to having mediators interact directly with proxies by retrieving the proxies and calling their methods? A colleague suggested that it would be a better practice to have mediators interact indirectly with proxies by dispatching commands that cause proxies to dispatch events which mediators listen for.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: February 05, 2008, 05:18:58 »

When reviewing the prior art before building the framework I weighed this issue heavily.

There are 2 schools of thought here:

School Numero Uno
Says have the controller be the only one that can write to the model, the view can read but not write.

This viewpoint particularly makes sense in the MVC2 paradigm that Apache Struts 2 is based upon:


This works because the view is always just reading the model and displaying it.

School Numero Dos
Both the controller and the view are able to read or update the model.

Client-side of PureMVC usage falls into the latter, because if the view has the knowledge of the model in order to display it, it already has a collaboration pattern and should also be able to update it.

If you don't want to use mediators to update proxies, then, quite simply, don't. Create a new command for each model update. This gets old after awhile when you're building commands that do nothing more than save the data that the mediator could've saved.

Here are the inputs to your decision of whether to update from a mediator or a command:

  1) If you are wanting this view component/mediator pair to be portable to other apps that use a different model, then send a notification and let a command do the work.
  2) If you have a lot of logic to do before the update, or need to collect data from other places before doing the update, etc, then do it in a command.
  3) If neither of the above apply then do your simple update from the mediator, save the hassle and overhead of the separate command, and refactor into a command later if 1 or 2 become true.

-=Cliff>
Logged
Pages: [1]
Print