Lately I’ve been using Model-View-ViewModel (MVVM) in Windows Forms application with great success. I really like using this pattern because it has made me getting even more code out of the View and into the ViewModel instead. One reason for this I believe, is that the ViewModel has no reference to the View and this forces me to have better discipline (compared to MVP) and the result is better separation of concerns. The advantages is also increased testability and looser coupling of the logic to visual elements, which eases change of visual representation.

In Glenn Blocks recent post, The Spirit of MVVM (ViewModel), it’s not a code counting exercise, he states (last paragraph of The essence and the spirit) that MVVM is only for WPF and Silverlight. He writes: “Because the pattern is specific and solely on the specific data binding, data templates, attached properties and command implementations found in the platform.” and then refers to PresentationModel (PM) as a pattern for Windows Forms. Also Josh Smith sees MVVM as a specialization of PM, only for WPF and Silverlight, in his MSDN Magazine article The Model-View-ViewModel (MVVM) Design Pattern for WPF.

For me it has been important to loosen up the coupling between the View and ViewModel/PresentationModel, by cutting the reference from the ViewModel/PresentationModel. I use the data binding features in Windows Forms to bind everything from the data to the state and the cursor. The data binding features aren’t as good as in WPF so sometimes I have had to use workarounds (see for example my post Binding Visible Property Often Requires Workaround). Windows Forms has no support or concept for Commands, even though that is possible to implement yourself, which has been done in for example CAB. This means that the View (=Form) catches the event itself, but then immediately delegates the work through a simple call to the ViewModel/PresentationModel.

So is MVVM only for WPF and Silverlight, being a specialization of PM? When Fowler describes PM he leaves it up to the reader to choose if the synchronization code should be in the PM or in the View, in MVVM the synchronization is done through data binding. This is also possible to do in Windows Forms. Left then is the missing Command pattern support which is possible to implement if you wish, so if I choose to do that, am I still not implementing the MVVM pattern? Am I still implementing the PM pattern with the specialization of requiring the synchronization code to not be part of the Presentation Model? Since I believe this is important, I would have liked to have a name of that pattern, but adding yet another to MVC, MVP, PM and MVVM will only bring more confusion.
This starts to look more like an academic question of which pattern it is. I will continue to say that I use the MVVM pattern since I believe that the requirement of the synchronization code to not exist in the ViewModel is more important than if the platform has support for Command pattern or not. As Glenn writes in his post, it is not a question of counting lines of code in the View that is important, but rather what kind of code that is left in the View. Having some simple lines of code delegating the events to the methods in the ViewModel is perfectly fine for me.