When reviewing the prior art before building the framework I weighed this issue heavily.
There are 2 schools of thought here:
School Numero UnoSays 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:
![](http://www.ibm.com/developerworks/library/j-struts/mvc2.gif)
This works because the view is always just reading the model and displaying it.
School Numero DosBoth 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>