CODEWITHSUNDEEP
c#wpfmvvm
Ben
Ben

Reputation: 1321

MVVM - Patterns and Practicality

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:

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:

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)

Upvotes: 3

Views: 1915

Answers (4)

Liero
Liero

Reputation: 27328

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

Upvotes: 3

user1269016
user1269016

Reputation:

I see it this way:

Model - Object that can be passed around. A Common type between different layers for communication.

ViewModel - Specifically created for Views. This should contain UI logic, for example, Data Annotations etc will go here. You might also call your web service methods here (assuming your actual business logic sits in a facade layer, or your database logic sits in a different layer/project) to populate the Views, dropdowns etc. You might end up with multiples of these per view, depending on your design.

View - UI Only.

I am not afraid to put external calls in the ViewModel

Upvotes: 1

Matt Cole
Matt Cole

Reputation: 2601

I like to think of the Model layer as anything that has nothing to do with how the app is hosted (i.e. independent of WPF). It is one or more dlls that represent the business domain and the operations that need to be performed in it. If it would make sense to take theses same dlls and use them in a web application, windows service e.t.c then it is usually a sign that the split between Model and ViewModel is appropriate.

Upvotes: 2

Paul-Mason
Paul-Mason

Reputation: 41

There's no simple answer to your question. The simplest answer is that the model and view model should contain the code that you should unit test. The separation between model and view model is a little less distinct. I like to keep the model as simple as possible and limit it to whatever is exchanged with the server tier. The view model should encapsulate the model, and provide any addition functionality (both business logic and abstract presentation logic) so that you can keep the presentation layer as simple as possible (declarative, in the case of WPF XAML).

Upvotes: 1

Related Questions