Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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
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.
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)
