MVVM or MVP for Winforms?

MVVM (Model-View-ViewModel) pattern  is more suited for WPF, while MVP (Model-View-Presenter) pattern  is more suited for Winforms. MVVM offers more benefits than MVP. It might still be possible to make Winforms support MVVM.  Hence I was trying to find whether it is beneficial to use MVVM over MVP in a winforms Application. I have summarized my findings below.

MVVM is more loosely coupled than MVP. In MVP, the View implements an interface IView and the presenter uses this interface. Since each view is different, it makes less sense to make each view implement the same IView interface. We might end up creating separate interfaces and Presenters for each view. With MVVM the view is aware of the viewModel, and the viewModel is aware of the model (but not vise versa). This means that multiple views can use a ViewModel and multiple ViewModels can use a Model. Hence MVVM is loosely coupled than MVP.

 

MVVM utilizes the features of WPF such as Data Binding, Commands, Data Templates. WPF (and Silverlight 2) features make MVVM a natural way to structure the application. This is not the case with Winforms.  Although Winforms supports databinding, you need to write some extra code to support two way data binding in Winforms by implementing INotifyPropertyChanged interface.  In the case of MVP, there is no need for two way data binding. The Presenter does the job of updating the view. You can also try creating a command manager for supporting Commands for MVVM, but it is much harder. Winforms do not support Data templates.  You can make Winforms support MVVM but you might not get all the benefits  of using MVVM in WPF.

If MVVM is properly used it is more testable than MVP.

The descision to use MVVM for Winforms is still up to you, based on your project needs.

Below are the few links I referred:

Niraj Bhatt on MVC vs. MVP vs. MVVM

Safe usage of INotifyPropertyChanged in MVVM scenarios

MVVM/Presentation Model With WinForms

MVVM for Winforms

MVC vs. MVP vs. MVVM

MVVM design pattern

Jason Dolinger has written a blog on Model-View-ViewModel in WCF. The blog has a video attached. In the video he talks about how to create Testable WCF applications.
Jason Dolinger on Model-View-ViewModel

Here is a brief summary of Jason Dolinger’s presentation

XAML is tightly coupled with the code-behind file. We usually write all the logic in event handlers in the code-behind files. This tight coupling of code-behind code with the UI will make the unit testing the code difficult. One more problem here is the View or the UI has become the storage place for data. Whenever you need some data you go to the UI controls to get the data. The View must just display the data and must not be storage place of the data.

Jason also talks about Model-View-Presenter pattern and how it is used in Winform/ASP .NET. In MCP, the Presenter acts as a controller. The view implements an interface. The Presenter is instantiated in the code-behind and an instance of the view is passed (injected) into the Presenter via the view interface. The presenter class is testable. You can create an instance of the Presenter, create a mocked view and pass it to the presenter. You can write tests against the methods in the presenter. The code-behind stays clean. MVP will also be applicable to WCF. But with MVVM we can take advantage of WPF two way data binding. Also you can avoid creating interfaces and implementing them.
In M-V-VM thee are three entities Model, View and ViewModel. View Model is a standalone C# class which acts like an adaptor between the View and Model. VM retrieves the data from the Model and displays it as properties. The view is databinded to the ViewModel properties (hence called the adaptor). VM contains public properties for each control in the View.

You can also refer A Practical Quick-start Tutorial on MVVM in WPF – CodeProject

I also came across an article that says using MVVM might be an overkill for small applications.

This links talks about an alternate implementation (MVP-PMlight approach)- The MVVM Pattern Is Highly Overrated

There are some guidance from Patterns and Practices about using Prism for WPF

 Prism, CAB, and WinForms futures

patterns & practices: Prism