MVVM - Patterns and Practicality

Question

I've been using MVVM for a while now with WPF. And i've learnt a lot over the course of development (going from never using it, to having a couple of applications developed in it)

However, recently I had some comments directed at the code which made me wonder if i'm doing things the right way. My current setup works (roughly) like this:

• Model - Responsible for storing the data, data validation using IDataErrorInfo and dirty tracking
• ViewModel - Responsible for getting the data (from a repository like pattern) and formatting it for a view's consumption (things like filtering, ordering) also responsible for command handling from the view (save, load, filter changes etc)
• View - The usual UI stuff

Now it was mentioned to me that i should NEVER have business logic inside the model, and that the model should be as thin as possible, the viewmodel should be responsible for handling things such as data validation and dirty tracking.

I've seen comments and criticism on both sides of this, with people against and for putting logic in the model, What i have yet to see is any actual reasons for these sweeping statements. So id love to know if there is an actual reason i should be refactoring my setup.

Also, given that i do move the logic to the viewmodel, I can see the need for having multiple viewmodels where i currently have a single, for example:

• Person - Model
• PersonViewModel - Handles the dirty tracking, data validation etc
• PersonsViewModel - Handles getting a collection of PersonViewModels, filtering etc
• PersonsView - The UI

This seems a little redundant, but perhaps i'm misunderstanding something. What I'm really looking for is some actual reasons for doing this one way or another, or if this is another argument like the use of code-behind in MVVM (pure opinion with little reasons etc)

Answer 1

High level description of MVVM:

• View: User Interface

• Model: Business logic and data (e.g Domain Model+Repositories, or Transaction Script+POCO entities, etc)

• ViewModel: Data exposted to view in such form, that is easily consumable from view. Wikipedia's definition says: The view model is an abstraction of the view that exposes public properties and commands.

I like the Practical MVVM Manifesto (archived version) principes: Simplicity, Blendability, Designability, Testability.

This is very high level and abstract description and that's why you may find a lot of variations of MVVM. Whatever mvvm style you choose, keep in mind the responsibilities and principles and you should be ok. Try to avoid complexity. MVVM is not a silverbullet and you cannot cover all scenarios with single design pattern. One mvvm implementation may be suitable for one application but not for another. I, for example, build my mvvm architecture from scratch for each new project to ensure the best fit

---

When is comes to responsibilities:

Take validation as an example: validation logic that password and repeat password inputs should be equal is clearly presentation logic and should be present in viewmodel. On the other side, there may be business rule, that password must contain at least one special character. This logic should reside in Model, however you may expose it in viewmodel to be easily consumable from view. It's a business logic, but you may need to present it somehow.

if you have application that only uses webservice to retrieve and store then your model will be probably just the data access components.

---

Here is couple of resources:

Wikipedia: https://en.wikipedia.org/wiki/Model_View_ViewModel.

MVVM is variation of Martin Fowler's MVP pattern, you may find it useful as well: http://martinfowler.com/eaaDev/PresentationModel.html

MSDN (Pattern and practices): https://msdn.microsoft.com/en-us/library/hh848246.aspx