Understanding WPF - store Data in Model or ViewModel

Question

I am unsure where to store Data in a WPF Application. There are two principles that might collide. Could somebody please clear this up?

Principle 1: Data should be stored in the Model.
It follows, that for example an ObservableCollection<string> Articles should be stored in the Model. A Property in the ViewModel could make it available to the View.

Principle 2: States relying on the View should be stored in the ViewModel.
That means that the string _SelectedArticle variable with corresponding Property string SelectedArticle should be stored in the ViewModel.

So far, I've put only Methods or values that don't affect the View into the Model, because I (maybe too) strongly followed principle 2. But I'm not sure if this is the right approach.

Should I really keep some Data in the Model and some in the ViewModel or is there a place to store all the data?

Answer 1

The simple answer would be: data should be stored where it belongs.

• The Model should contain only data itself - it may contain data that you got from external services, user input, data access layer and other.
• ViewModels should wrap parts of the data, which will be presented to the user, into proper wrappres to provide users with the ability to view and change data - public properties, ObservableCollections, etc. If there are many visual representations of the same data in your app, then you must build appropriate ViewModel for each representation (View).
• View consumes ViewModel, but additionally can have (and store) some validation (not verification) logic and associated parameters in it.

In your case the Model should have List<string> Articles. ViewModel will consume this list and build ObservableCollection<string> Articles in the constructor. And SelectedArticle should be stored in ViewModel too, if its value used only for navigating within View and will never be used in Model or saved to DB somewhere in Data Access Layer.

Answer 2

The model should contain all the data that needs to be saved, so for example a person object the Model contains the Firstname, Surname, date of birth etc.

The viewmodel then wraps this model and applies any logic needed to pass data between the View and the model, so if you want am Age field then you don't save the age in the model you instruct the view model to calculate it from the DOB and pass that to the view, likewise business rules such as validation of inputs happens at the View model level, so if your person has to be over 18 you'd check the date of birth before passing it to the Model for saving, you also use the view model for change tracking so if you change the First name its the view model that raises the property changed event not the model

The view then controls how to display the data, so instructs which controls link to which properties in the ViewModel

Most controls that are selectable will have their selected value defined as part of the functionality so if you want control A to display what is selected in control B then bind control A to control B's selected item property

in your case i would expect to see an Article Model that controls database access or web services etc

an ArticlesEditor ViewModel that displays the article text, allows it to be changed with a Save and cancel method that either reloads the orginal text from the Model or copies the changed text to the model

then an ArticlesList View model that contains an observable collection of ArticlesEditor and contains the methods for creating and deleting articles

then on your view you would have a listview bound to ArticlesList.Articles property and your editor control bound the the ListViews.SelectedItem property, the editor control's controls would then be bound to the properties of the ArticlesEditor object

Answer 3

All data visible to View should be stored in ViewModel. Just use viewmodel that calls your business logic. Model should be used if your entity not mapped to view, if you display something, than its viewmodel.