.net – Always use MVVM in a WPF app, or are alternative patterns still practical/useful

design-patternsmvpmvvmnetwpf

On page 374 in the book Microsoft .NET Architecting Applications for the Enterprise, there is a chart regarding the evolution of patterns for the presentation layer and their impact on platforms (figure 7-14).

In addition to showing the evolution from the original MVC pattern, to the more modern variants, that chart also shows that the following modern patterns can be applied across the following technologies:

Model2 (MVC)
- Web Only
Passive View (MVP)
- Web
- WinForms
- WPF
Supervising Controller (MVP)
- Web
- WinForms
- WPF
MVVM (Presentation Model)
- WPF Only

Note: One other recent pattern of interest lately not in that chart is Presenter First (MVP) which was envisioned to be more accommodating of TDD.

From what I understand if one develops with WPF, then the MVVM pattern is the de facto choice (kind of like Model2 is for web development). That said, it appears nothing prevents one from using Passive View, Supervising Controller, or Presenter First in a WPF app. Such an approach would result in an application that doesn't really care if the front end is WPF, WinForms, or the Web. It appears that these MVP variants allow more flexibility.

However, does aiming for UI-platform-agnostic flexibility (that might not be needed) come at the cost of making WPF development much more difficult and lose out on a portion of the features/power that WPF offers? So much so that the costs outweigh the benefits?

In other words, is MVVM so great that one shouldn't consider other alternatives in WPF applications?

Best Answer

According to the included documentation in MVVM for WPF (page 2 of the general introduction)

The origins of this pattern are obscure, but it probably derives from the Smalltalk ApplicationModel pattern, as does the PresentationModel pattern described by Martin Fowler. It was adapted for WPF use by the Expression team as they developed version 1 of Blend. Without the WPF-specific aspects, the Model-View-ViewModel pattern is identical with PresentationModel.

Going to Martin's Fowler's website and looking up Presentation Model we have this

Compared to Passive View and Supervising Controller, Presentation Model allows you to write logic that is completely independent of the views used for display. You also do not need to rely on the view to store state. The downside is that you need a synchronization mechanism between the presentation model and the view. This synchronization can be very simple, but it is required. Separated Presentation requires much less synchronization and Passive View doesn't need any at all.

For my own metal cutting CAD-CAM application I use Passive View. The reasons for this are

To making testing easier by having mock objects implementing the view thus allow the vast majority of my software's functionality to be automatically tested
To reuse not only the core model but the different views for related types of metal cutting software.
To clearly document the interaction between the views and the model.
To destroy any dependency on the GUI toolkit as this software has been continuous development since 1985 and seen several major changes in the underlying tools, APIs, and even the language itself.

The the concerns of first three can be handled by the MVVM, Presentation Model, Supervising Controller pattern. But only the Passive View addressed #4.

As stated by Martin Fowler only the Passive View doesn't require any synchronization method. MVVM is a implementation of Presentation Model for WPF. You are dependent on the XAML interface to tie the view state located in the View Model with the View itself. So if at a later time you change the UI or it's APIs then your View Model will be changed as well.

In contrast Passive View only requires that the new UI elements implement the View Interface. It doesn't matter what they are actually connected to also as the form or controls implementing responds correctly.

But the price is that you have an extra step when implementing new elements of a view. You have to decide how they are to be presented to the presenter and at what level of abstraction. It is enough that it over kill on some projects or for some types of UI like dialog boxes.

The short answer to your question about MVVM being THE way for WPF, the answer is no it is not. It is a tool that need to be considered in light of the other issues surrounding the development of your application.

EDIT:

There are two variations of the MVP pattern (a) Passive view and (b) supervising controller

For complex databinding scenarios I prefer to go with the Supervising controller pattern. In supervising controller pattern the databinding responsibility rest with the view. So,for treeview/datagrid this should be in the respective views, only view agnostic logic should moved on to the presenter.

I'll recommend having a look at the following MVP framework MVC# - An MVP framework

Don't go by the name (it's an MVP framework).

Simple winforms MVP video Winforms - MVP

An example of dealing with dropdown list MVP - DropDownList

Simple treeview binding example (poor man's binding). You can add any treeview specific logic in BindTree().

Below is the code snippet.... not tested, directly keyed in from thought....

public interface IYourView
{
   void BindTree(Model model);
}

public class YourView : System.Windows.Forms, IYourView
{
   private Presenter presenter;

   public YourView()
   {
      presenter = new YourPresenter(this);
   }

   public override OnLoad()
   {
         presenter.OnLoad();
   }

   public void BindTree(Model model)
   {
       // Binding logic goes here....
   }
}

public class YourPresenter
{
   private IYourView view;

   public YourPresenter(IYourView view)
   { 
       this.view = view;
   }

   public void OnLoad()
   {
       // Get data from service.... or whatever soruce
       Model model = service.GetData(...);
       view.BindTree(model);
   }
}

Best Answer

Related Solutions

.net – Handling Dialogs in WPF with MVVM

Winforms – UI Design Pattern for Windows Forms (like MVVM for WPF)

EDIT:

Simple treeview binding example (poor man's binding). You can add any treeview specific logic in BindTree().

Related Topic