I'm still new to MVVM and am trying to understand the concepts.
I have a class generated by Linq To Sql for a table.
I want this class to look different, so I create a new class with some of the properties from the generated class and a few new properties, that is only dependent on generated class.
Is this class a model, a view model or something different?
ViewModel represents the state and behavior of the View. I would call a class a ViewModel if:
It provides property change notification through INotifyPropertyChanged
Has commands for the view
Provies a model for the view, by specializing the model for easier data binding (formatting etc)
Could be a View Model, but not necessarily. Are these extra properties there for the purpose of supporting a view. If yes, then you could argue that it's a view model class.
View Models exist because views exist. Models exist because you have a domain of data. the View Model greases the skids between reality (model) and a given users perception of that reality (the view)
Related
I am trying to understand the MVVM pattern and I don't clearly get the responsibilities of VM and M. I am trying to work on an wpf example with a Person class (with firstName, lastName and dateOfBirth). I have created such a class in my Model folder. Now I want a collection (an ObservableCollection) of the Person class that I want to bind to my View. Where should I maintain this collection? In ViewModel or Model?
Here is tutorial They created very similar program to yours.
In MODEL you should have class Person and add persons to collection.
In VIEWMODEL ICmmand etc. Read data from Model and push to View.
In View just display data.
I'm trying to learn MVVM, and i'm struggling a little on differentiating between a model and viewmodel.
If someone could answer these 2 questions it would help clear a lot up for me:
Say I have an Objects class, which is a viewmodel that contains multiple ObservableCollections of Object.
The Object class contains an ObservableCollection of strings that are displayed on the GUI.
Is the Object class a model or viewmodel?
What if the Object class contains just a string and a integer (name and value), is it a model or viewmodel?
The Model is the class that holds your data. The data can be strings /integers or whatever.
The Model can also be a list / collection of those objects. For example a List of Person objects can still be your Model.
The ViewModel is the tier between your Model and the View. It should be used to perform whatever tasks you need on the data (for instance, if your Model is a list of Person objects but you only want to show in your view people that are aged older then 18, this logic is done in the ViewModel)
So to answer your question:
If you have an object which contains the data (in your example a list of strings) it is the Model.
Even if the object is a little more complex (with relation to the number of properties it holds) it's probably still the Model.
Business Logic should be kept separate from the model. On the other hand Validation can be added to the Model (for instance to make sure the Age property of a person is non-negative) since this is still rules on how your data should behave
I know that mvvm calls for having a ViewModel class that wraps a Model class, but I'm wondering why it's a better practice to do this rather than just enhancing the Model class directly via partial classes. I get that you might want the Model to be auto-generated from an ORM, but you can still put the ViewModel stuff in another file via a partial class, and doing this avoids the considerable overhead of maintaining a ViewModel for every Model. So I guess the question is: what's so bad about letting the Model have UI oriented code, as long as you separate it in the source code and don't use the UI aspects of the Model inappropriately?
The point is separation of concerns. Your ViewModel is built specifically for the needs of the UI; that means the data it contains is formatted specifically for the UI, whereas your Model is formatted directly for your persistence or domain logic.
In your situation, changing your model necesarily requires then that a change is also done to the view model; when separated, each can vary independently which reduces unintended side effects.
what's so bad about letting the Model have UI oriented code, as long as you separate it in the source code and don't use the UI aspects of the Model inappropriately?
Nothing if you have a complete set of unit tests and are willing to update all locations that are using your model if it changes, or if you can guarantee that your database will never change.
You can't really "enhance" your Model instead of using a viewModel. In theory you could, but it would be very bad code.
Just a simple example:
Imagine that you have a class User with only 2 fields: userName and password. This User class is your model.
But on your page you want to add one more field to edit/add the data: the password verification field.
So are you going to add password2 field into your User class?
That's bad!
Instead you better create a ViewModel binded to your View and based on the data of your ViewModel then you create the instance of your Model and process it in the other layers
A "Lookup" in this example is an IList<string> of state abbreviations. Generally, your Domain Model POCOs won't include these options. ViewModels usually take this responsibility referencing both the original Domain Model as well as the Lookup object, but what happens when the Domain Models are nested and you are using MVC templates (which won't have access to the original Model's root properties?
Is there a way to include the Lookups in one object and the Model in a different object for the template? Is it permissible to assemble on-the-fly a ViewModel specific to that Template within the View (which would have to include any nested data from there)? I would think static methods to pull down Lookup values is bad.
Any ideas?
Notes (to my knowledge):
A Domain Model POCO from a repository doesn't change in structure. If you need a single Model to have both the Customer object and the DDL options for US State for example, you normally have a ViewModel that references the Customer object and the Customer Lookup lists.
However, when you have a nested Domain Model (aggregate root), the nested objects have no where to put the Lookup Lists, and the MVC templates cannot access the root level View Model (their view model is the partial Model).
Edit:
Is there some way to put the DDL lists in the root level of the ViewModel, then when you get to the Customer object, construct a new ViewModel that references the root level DDL lists and the current Customer object to send to the template? This would eliminate duplicate data in the Model as well as use a single Model for all the Views. The only bad would be Controller like data assembly code in your view (which is just as bad).
A couple of suggestions. First, use separate view models for your views -- don't directly use your domain models. These view models can, and should, carry the extra data needed by the view. Second, you can use the overloads on DisplayFor/EditorFor to pass additional view data to the template. That way your template can be specific to a particular domain model and yet have access to the additional data in the view model.
For static, unchanging lists like state abbreviations, you could use Application state or Cache entry. These types of lists could be loaded in Application_Start from a database.
Is Model only Entity Data Model class of my database? Model as simple place where i have my data? Or I can input in Model something more?
The model in MVVM is supposed to be the place for data-centric logic and the data, yes. It can be just the Entity Data Model, or you can add some more logic--that's up to you. The primary point is to seperate any presentation-specific logic from the model and put that in the viewmodel.
Hope that's clear enough
You can do whatever you like...
Typically, though, the "model" in MVVM is considered to be an "external" class (e.g. a generated class from LINQ-to-Entities, say) and so it usually doesn't have much logic.
The model is the core domain logic you are dealing with. It is everything not directly related to a UI view.
An easy way to think of it is the View and ViewModel combined represent what would be a "typical" UI layer without good separation. In MVVM, you split the logical aspects (the ViewModel) from the display logic (the View).