In class today we were introduced to the MVVM architecture for Silverlight/WinPhone/WPF; it looks nice for big projects, but what are your thoughts on MVVM?

What are the pros and cons?

I want to get more into the architecture so that I know when I should use it.

closed as too broad by gnat, durron597, user40980, Kilian Foth, Bart van Ingen Schenau Oct 15 '15 at 10:58

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


MVVM is (yet another) variation on patterns that separate the concerns of a typical presentation, much like MVC and MVP. Regardless of these variations, the basic concerns are the following triad:

  • the Model (the underlying data and domain objects).
  • the View (what the user actually sees and interacts with)
  • the facade that translates between the Model and View. (the ViewModel in this case)

Doing so leads to benefits on it's own that have nothing to do with the platform technology including the increased testability that comes from taking logic that might be lumped into the View otherwise.

The particular slant in MVVM's ViewModel is that it promotes the use of data binding, which is a strong suit of the technologies that tend to use it (wpf, silverlight).

Theoretically, that's it! In practice, this implies skills and experience with data binding. OOP, and testing - so there may be a learning curve. There is also several ways to execute the pattern, so the first few attempts may seem a bit overwhelming.

But you will have the security of your tests as you gain experience and refactor towards more elegant usages. Testing is essential to any non-trivial project IMO, regardless of its ultimate size. Did I mention that MVVM promotes testability?


The thing I like most about MVVM (besides the test-ability), at least from a web UI perspective, is that I don't have to write a bunch of plumbing code to wire-up all my event handlers to the page... It's also much easier to think in terms of behaviors and distinct units of responsibility when using this approach.


In my experience small projects that are successful become big projects. So always assume your project will be a success and plan for the future. Design it is such a way that you can add on functionality with out forcing it in.

So MVVM is a great tool for just that. Once you set up a few projects and get the hang of it you will find there really is not that much overhead it is just shifting the work from as you go to up front. And once you are ready to go you can take off and create your application. As for when to use it anytime you need a robust dynamic user interface.

Not the answer you're looking for? Browse other questions tagged or ask your own question.