Menu
In the MVVM Pattern, is there exactly one ViewModel per View or is there exactly one ViewModel per Model?
842
ViewModel is nothing but a single class that may have multiple models. It contains multiple models as a property. It should not contain any method. In the above example, we have the required View model with two properties.
For a best mvvm pattern implementation each view must have the own viewmodel, and don't share anythings with other.
The same ViewModel factory can be used for multiple ViewModels when they share dependencies, as it's the case for the Architecture Blueprints sample.
Models are just the plain data, and a ViewModel is something that acts like a padding in between the two, that it should get information from the Model and pass it onto the View, and the View should know how to present it.
The ViewModel holds data related to actually viewing the Model, and that data is going to be different depending on how you view the Model. For instance, it's going to need a Selected property for a paginated grid View, and a SaveChanges command in an editing View, neither of which is relevant to the other View.
MODEL: ( Reusable Code – DATA ) Business Objects that encapsulate data and behavior of application domain, Simply holds the data. VIEW: ( Platform Specific Code – USER INTERFACE ) What the user sees, The Formatted data.
One ViewModel can have several Views (in practice) usually only when you have shared ViewModels for, for example, DesktopApplication (WPF), Web Application (Silverlight) and Windows Phone. Something like this. But usually - one ViewModel - one View. If you have several Views for one ViewModel - usually you will have a lot of maintaince problems...
There is one model per viewmodel and one viewmodel per view, in the other direction everything is n. Show activity on this post. Can you explain what this means? I don't understand what this is saying. Are the dashes meant to be minus signs (n-1) or are they dividers? What does the n mean? Show activity on this post.
Theoretically, relationships are
View n - 1 ViewModel n - 1 Model
I know, a lot of people will bite and beat me, but... In practice...
Very often, in business applications, there is data access layer (DAL). And very often entities from DAL are your Models. Sometimes you should wrap those entities with additional classes to provide extended functionality or maybe some additional properties. Maybe you have your own Models...
ViewModels and Views (in practice) usually have 1 to 1 relationship. Something like - every screen (or part of screen) is actually a paired View and ViewModel. I think usually just something like - View is UI layer and ViewModel is code-behind level. View is just XAML file - presentation layer. And (the best practice) everything else should be in ViewModel - all data receiving processes, all commands, all changable fields etc. This way you can usually test ViewModel (with unit testing). One ViewModel can have several Views (in practice) usually only when you have shared ViewModels for, for example, DesktopApplication (WPF), Web Application (Silverlight) and Windows Phone. Something like this. But usually - one ViewModel - one View. If you have several Views for one ViewModel - usually you will have a lot of maintaince problems...
60
There is one model per viewmodel and one viewmodel per view, in the other direction everything is n.
33
View n - 1 ViewModel n - 1 Model
29
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
