MVVM in WPF - Some uncertainty

Question

I've been dealing with WPF in the last time and I'm trying to understand MVVM, but there is a bit of uncertainty: The data is inside the Model and the View binds to the View Model, right? But is there really just data inside the model or is it legit to have for example a save method or a method which picks up the data from a database inside the model?

The next thing is: I'm binding to the View Model and obviously there is an instance of the Model inside the View Model. So I encapsulate the data from the Model instance again in the View Model, so I can bind to it although the data is already encapsulated inside the Model? I saw several implementations which had the main data inside the View Model and encapsulated the fields which were inside the View Model and not inside the Model, so how to do it the right way?

And the third uncertainty is: What's the common way to validate the data? Inside the Model with a IDataErrorInfo or inside the View Model's encapsulating? I found several implementation of the MVVM-Pattern on the internet and some of them were so different to the next, that I'm unsure how to manage these things.

Answer 1

The data is inside the Model and the View binds to the View Model, right?

That's the general idea, but the "Model" is not always a single, clearly defined entity.

But is there really just data inside the model or is it legit to have for example a save method or a method which picks up the data from a database inside the model?

There may be a combination of data and data services encapsulated by the Model and/or View Model.

Logic is typically initiated through commands exposed by the View Model. These commands may hand off the real work to other services, or the work may be done entirely within View Model, or possibly the Model, depending on your design.

The View Model tends to encapsulate logic related to the presentation of the data, e.g., managing things like item selection. The logic related to loading, saving, and querying the data is usually initiated by the View Model in the form of a call to some service that performs most of the actual work.

So I encapsulate the data from the Model instance again in the View Model, so I can bind to it although the data is already encapsulated inside the Model? I saw several implementations which had the main data inside the View Model and encapsulated the fields which were inside the View Model and not inside the Model, so how to do it the right way?

The "Model" is the most loosely defined component in the MVVM pattern. Often, developers will not bother with two layers of encapsulation, and the "Model" is simply taken to mean "the data", which is exposed/encapsulated by the View Model. This is probably consistent with code you have seen. I tend to think this is fine, provided your data is "MVVM-friendly", e.g., it implements INotifyPropertyChanged, supports validation (if desired), etc. If you don't "own" the design/structure of the data, and the data is not well suited for direct binding, you may end up creating 'wrapper' models for your data (in effect, mini View Models). In my experience, this is often unnecessary.

What's the common way to validate the data? Inside the Model with a IDataErrorInfo or inside the View Model's encapsulating?

The most convenient solution is for the object(s) you are binding against to implement IDataErrorInfo, as this simplifies integration with WPF's data binding system. Usually this means the Model (which may simply be "the data", depending on your design).