Question

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:

1. Model2 (MVC)
   • Web Only
2. Passive View (MVP)
   • Web
   • WinForms
   • WPF
3. Supervising Controller (MVP)
   • Web
   • WinForms
   • WPF
4. 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?

Answer 1

@RS Conley’s answer is giving a very broad into to the subject, and I agree with most. The only thing I think differently is in the bottom line.

MVVM is THE architecture for 95% of applications in WPF.

Choosing any other architectures is means settling for something that is less than the best you can get. In RS Conley’s situation Passive View might be the best way to go, but that is far from being the normal case.

As a way to understand how MVVM is better, let’s see what’s he’s losing when he’s going the PassiveView approach.

Maintainability

In Passive View, the ViewModel knows about the IView, which means that SRP (Single Responsibility Principle) is not kept. The Controller in PassiveView interacts directly with both the Model and the View, and therefor is doing two completely different things!.

Under MVVM, the ViewModel, which is the heart of the application only have one concern, which is to contain the state&logic of the application. The Maintainability of such code is really superior to PassiveView, MVP or MVC treamendously.

It is true that PassiveView is better when it comes to Automated Tests Coverege, but IMHO, good maintainability of code is far more important.
Testability helps u make sure you don’t break your code, while Maintainability helps you not to build problematic code to begin with.

When it comes to Maintainability, MVVM and PresentationModel are an evolotion of previous UI architectures, and that’s because the SRP principle is kept very strictly. Write enough code in MVVM and you’ll see what I mean.

Blendability

Another Feature where MVVM is really strong is Blendability.
Since all of the application state is preserved within the ViewModel, it is easy to fake data for design time, which allows enourmous boost to productivity.
This is impossible to create in PassiveView, MVP or MVC, because in all of those architectures the controller has to actively put data inside the view. In MVVM the data just “jumps” to the View and therefore can be mocked.

Testability

This is indeed a place where PassiveView is superior to MVVM. If 100% Unit Tests coverage of UI is crucial to you then it’s a big deal.
In most situations however, the coverage that MVVM allows you is more than enough, and you’ll usually add another tier of testing using regular UI Testing (which you’d end up doing in PassiveView also btw).

I think that Testability is the less important of the three features. Sorted by importance, it’s Maintainability, Blendablilty, and Testability.

Where is MVVM not the right choice?

I’ve participated in ~ 15 WPF & Silverlight Projects the last year, all of which MVVM fit perfectly. I think that in places where the presentation logic is extremely big, such as in games, MVVM might not be the right choice.
Other than games, I can’t really think of an application category that wouldn’t go best with MVVM, other than special situations like RS Conley mentioned.