Could you tell me what is the goal of the MVVM pattern? What are the arguments or the reasons I can give to a team and product owner to respect and develop according to this pattern?

I would like a simple answer. Something in one sentence or one word. Is it for

  • maintenance
  • security
  • testing
  • something else?

closed as too broad by gnat, user40980, GlenH7, Robert Harvey, Bart van Ingen Schenau Apr 9 '14 at 7:04

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.

  • "There are either too many possible answers" So I was wrong... I conclude the answer is subjective or there is no real or clear reason to use MVVM pattern. Thank you for this clear answer. – Bastien Vandamme Apr 16 '14 at 16:48
  • The close reason is not an answer to your question, it is a description of problems with your question itself. – Robert Harvey Apr 16 '14 at 17:11
  • Possible duplicate based upon edits: programmers.stackexchange.com/questions/105352/… – GlenH7 Apr 16 '14 at 17:57

My simplistic answer is that in the standard MVC concept, the Model knows nothing about the View. However, on GUI platforms that support data binding, the View needs bind to something that is responsive to changes in what the user sees, and the Model cannot satisfactorily fill that role. Data Binding is a Good Thing, but not easily reconciled with MVC.

The ViewModel is specifically a set of data structures provided for data binding, so that it can contain all the data items required by the View and be updated as necessary, without polluting the Model. In doing so it acts as a layer between the View and Model, where both the Model and ViewModel are updated by the Controller, often via event driven code.

I'm not convinced that Microsoft invented it, but I do think it originated in the Microsoft community, since data binding is a prominent part of Microsoft architectures (particularly those based on XAML).

Wikipedia is pretty good: http://en.wikipedia.org/wiki/Model_View_ViewModel


MVVM is basically just a modern refinement of the MVC pattern, so the main goal is still the same as that of MVC: to provide a clear separation between domain logic and presentation logic. This can be boiled down to code quality: by adhering to the concepts of high cohesion and loose coupling, you stand a much better chance of sustaining productivity over time. Clear separations of concerns simplifies the use and maintenance of your code, and loose coupling between components makes testing and code reuse easier.

That would be my general argument for using MVVM over not using any such pattern. Whether it's a good idea to use MVVM in particular over e.g. MVC or MVP is indeed subjective and depends on the application.

  • Ok and separations of concerns for what? Same question security, maintenance, testing or something else? – Bastien Vandamme Apr 16 '14 at 16:54

The basic reasons of using MVVM are Separation of Concerns (SOC) and Single Responsibility Principle (SRP). Then you have Flexibility, Maintenance and Testing.

The goal of MVVM was to apply the above on WPF. WPF provides "plumbing" to allow easy use of MVVM through Data Binding.

For SOC and SRP read: Separation of Concerns(Wikipedia) and Single Responsibility Principle(Wikipedia). But the basis is: The logic doesn't care that the button is red and situated on the left top corner. Only the UI cares about it.

Flexibility on this case is the ability that one ViewModel can provide to different Views, or one View can use several ViewModels, that one ViewModel can use more that one Model, and that a Model can be used on separate ViewModels.

Maintenance is a consequence of SOC and SRP. It is much easier to change parts of the code or UI without affecting other sections.

For Testing, now you can do automated testing of your logic without having a window pop up. You can isolate the tests and mock whatever is needed (if at all).

To the product owner what you have to say is that it will become easier to make changes and to affirm(test) that the application is behaving as expected.

To the developers: it will make your life easier.

If you are not using WPF, maybe look into MVC(Wikipedia) or MVP(Wikipedia)

  • SOC and SRP are not the same thing. I understand MVVM is for SOC but I don't see where MVVM respect or has to respect SRP? I always thought MVVM was for DIP. – Bastien Vandamme Apr 16 '14 at 16:58

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