The Model View View-Model pattern gained a lot of momentum lately. It allows to reduce the code in the code behind class of a form or user control to a minimum. Therefore, unit testability is improved dramatically compared to other view patterns like MVC/MVP.
However, when I design software, I follow (amongst others) the principles of SOLID (link).
The first principle in SOLID is the Single Responsibility Prinicple (SRP) that states that “A class should have one, and only one, reason to change.” (link)
And here start my concerns about MVVM.
After searching through the Web to find good examples of MVVM (e.g. video, article) I came to the conclusion that
- MVVM is really a great pattern to decouple the graphical representation (xaml) from the behaviour (code)
- MVVM applied like in all samples I found will lead you on a dangerous way because of the violation of the SRP
You ask why? Think a moment about where you would put these aspects in MVVM:
- translation of data (e.g. content in list box)
- mapping of domain data to view-model “model”
- actions taken on domain model
- permission handling (what to show and editable/read-only behaviour)
These are all seperate responsibilities. Therefore – applying the SRP – they should be handled in different classes. In MVVM however, they are all handled within the View-Model.
You ask for a better solution?
Me, too. And I’m working on it (Sample Application) by combining the Passive-View-Command pattern with MVVM.
If you struggle with the same concerns, please share your thoughts in a comment.
UPDATE: see here for my solution to this.
Hi Urs
You are absolutely right and I see no reason, why the listed aspects should be handled in the View-Model. I’m looking forward to see your sample application, how you going to solve it.
PS: It’s often the first and straight forward approach to put too much responsibility in one class. That’s not primarily a problem of the MVVM approach.
Cheers
Thomas