Slides 30, 31, 25 of this presentation http://www.slideshare.net/simbo1905/design-patterns-in-zk-java-mvvm-as-modelviewbinder come to mind when I read this discussion.

With pure bindings the ViewModel has no compile time references to the View. The Binding technology has a primary role. Draw it as a triangle with the Presenter at one corner pushing data into the View then it is the Mediator which has compile time references to the View. The bindings there are optional (slides 23, 25).

What I am taking away from the discussion is that in SL where the pattern is “client side” the dispatch and plumbing to the server should not be “mounted” into the poco the View is bound to. Instead use the poco as the abstraction of the view that a controller pushes up into.

On the flip side if you are not in SL and are doing MVVM in WPF fat client with ORM then the “remoting and dispatching” plumbing may not be a barrier to working directly with the model. Then the bindings can “pull through” the Model through the ViewModel to update the View. Regular commands going down then don’t need much plumbing and you can move your Use Case service Mediation logic into your ViewModel without the headaches of SL event dispatching to the server and the callbacks. 

What I am taking away from the discussion is that in SL where the pattern is “client side” the dispatch and plumbing to the server should not be “mounted” into the poco the View is bound to. Instead use the poco as the abstraction of the view that a controller pushes up into.

On the flip side if you are not in SL and are doing MVVM in WPF fat client with ORM then the “remoting and dispatching” plumbing may not be a barrier to working directly with the model. Then the bindings can “pull through” the Model through the ViewModel to update the View. Regular commands going down then don’t need much plumbing and you can move your Use Case service Mediation logic into your ViewModel without the headaches of SL event dispatching to the server and the callbacks. 

To me Davy’s is saying “the plumbing of the mediation” gets in the way and that a “simple formatting model” with “separated controller” works better for him. Saying that ViewModel is a PresentationModel misses the distinction between mixing the orchestration of the Model into the ViewModel else keeping it separate. 

I think that the reason that MVVM is so much alphabet soup to most people is that after half a decade the documentation does not yet pick up on Mediation being (a possible) facet of the pattern. It is of course optional; but I think it is central to what Davy is discussing and is at the root of the mis-understanding which lead to the flame war here….

The presentation / discussion of the patterns are at http://www.slideshare.net/simbo1905/design-patterns-in-zk-java-mvvm-as-modelviewbinder and the sourcecode is at https://github.com/simbo1905/ZkToDo2

What is interested is what I described as desktop MVC which is using Bindings of the View to the Model. The model is updated from commands on a Composer (a not-so-supervising controller). This seems to me to be what Davy is advocating (MVP+Bindings == MVP+PM). There is a dedicated article on that http://java.dzone.com/articles/using-desktop-model-view 

So having (hopefully) shown code for all three patterns discussed here let me wade into the debate… 

I agree with @ac2dd23ded65763235b3b439ec326d50:disqus  that the hope is that the ViewModel has a single role; to model the GUI. Whether you are going to get a nice coherent ViewModel is down to how much impedance mismatch you are going to get trying to mediate your Model to the View.  

By way of an example if your model is something like remote service rapping a dao which is stored procs then your going to have a lot of plumbing to deal with the remote calls and remote errors. If the data you get back is raw database values you are going to want to wrap it with a simple Presentation Model which does the formatting for the screen. That is clearly two concerns which may naturally fall into two sets of classes. 

You would be annoyed if you had to maintain code which tried to pretend to be a POCO but which did service lookup and remote calls in its getters (no really, it happens). Such “mystery guest” objects may benefit from a refactor into a business delegate (mediates the remote calls) and a presentation VO (a weak ViewModel or a simple Presentation Model). Having seen such code I am thinking that these are the sorts of messy ViewModels which Davy seeks to avoid. The more logic in the remote service layer; the less there is for the “client side” to do other than just the plumbing, the formatting, and the layout. The more these fall into different SOC classes. 

On the flip side if you don’t have a lot of in-your-face remote plumbing between your View and your Model then you might not find there is no problem with a rich ViewModel. Desktop apps are more likely to have less in the way (e.g. some ORM). With almost no Service Layer logic then why not have the ViewModel do mediation of the data access layers? Why not have it be the “app logic” and hold the user session objects and manipulate them then persist them in the services with a View bound onto it?  

The best choice is not the pure pattern; the best choice is the one which work in the context of your code and its deployment. If your context works better separating Mediation from Presentation then Davy recommends MVP+PM (or I would call it MVP+Bindings). If you are not getting bogged down in the business delegate plumbing then people are recommending MVVM which mixes both mediation and conversion of your Model to your View.

By just following along some popular flavor of the month pattern code you dragged from the net is the new bane of programming.  First you need to understand the basics of programming and how to evaluate what is best. The human mind is a tool which craves properly carved blocks.  What is best is how your mind accepts them regardless of any principle.  It this way it is an artform, which people seem to have forgot or I am starting to realize people never knew…  The first rule is, human ergonomics.  Furthermore, contrary to popular belief that may not be pattern at all my friends.  Patterns cut blocks into sizes which are incorrect for contexts, therefore they will always be inferior despite consistancy.

This is very similar pattern to Silverlight RIA.  In RIA the ORM becomes an asynchronous callback method that when ready posts the data back.  The load of the data is then handled via binding when the source is set in the callback.  In fact my MVVM ideas were stolen from RIA.

So what happened?  Did all the people begging for code look at it once you posted it, and finally understand what you were talking about?  I notice there was not much further debate after the code got posted.

and you have the same result. In your communication via a service reference then the model really begins in the client area, not what the server gives you.

Skin it how you will, it’s really all the same thing.