What goes into the Model/Viewmodel?

问题:

what goes where?

This is a short description of my C# project:

I have a mechanical construction (only one in the whole program), described by some 20 to 30 parameters (deimensions, material parameters etc.), that may, as a complete set, come from an input screen or from an XML file (Deserialized). These parameters must then be processed in a calculation to generate output, that goes to a JPEG file and also to an HTML file.

The View is clear: it's the IO screen.

The View needs an ViewModel where the Properties are. Maybe:

My Model is the construction at hand, that is described by its parameters. Those parameters however, are the same ones that are gathered from the IO screen , the View or from XML.

Some output (the JPEG file) also goes the View. It might be a Property that Notifies it's changed.

Now my question is, do I need a Model at all, because the ViewModel has all the properties already.

Or, do I need a ViewModel at all, because my Model has all the Properties to be Viewed. I could define a Model in the ViewModel (like it is always done in MVVM) and use the Model as a DataContext for the View. But that last option would make the View aware of the Model: not in the MVVM spirit.

回答1:

I've written this multiple times already, but I'll do it once more...

The main reasoning behind MVVM is to separate layers and to avoid tight coupling as much as possible.

That said, View is, as you've correctly guessed, the UI. Things your user sees. It doesn't matter if it's a Windows, a Page, a custom control, webpage or even a console (when we talk about MVVM in a broader context).

ViewModel is a mediator between your model and the view. It takes, combines and manipulates your methods and properties from the model for the purposes of the View. It doesn't care how, when and where are these used. It also can trigger actions on the model side, for instance call services that take care of updating your database.

Model is EVERYTHING that isn't tied to the specific platform. It's classes of your business logic, it's database entities etc. It's basically your application stripped of any ties to the UI implementation. This is what people get wrong and think that model are only database entities. That's simply wrong!

---

To answer the question you've asked: "Now my question is, do I need a Model at all, because the ViewModel has all the properties already."

Yes, you should, otherwise you'll end up coupling the view directly to the model and that's violating MVVM principle. Your View shouldn't know ANYTHING about the model directly. As far as View cares, every one of the properties and methods can be coming from a different project. It won't change a thing and the view will still function the same.

You maybe don't see it yet, but in the future it will make your life much more easier. The code becomes easily maintainable if done correctly, much more readable etc.

回答2:

In addition of what @walter said, you can check this Codeproject entry which explains flawlessly the difference and a little bit more. That article helped me to undestand when I was beginning:

http://www.codeproject.com/Articles/100175/Model-View-ViewModel-MVVM-Explained

回答3:

In short:

Model: A class that represents data, it shouldn't do anything. It's good practice to implement INotifyPropertyChanged, however it's not required if you don't need to change the data from the View.

ViewModel: A class that exposes the model as a public property so that the view can bind to it. It should contain methods that interact with the model. It could also contain properties of it's own.

View: Binds to the ViewModel, where it can access the model, and ViewModel properties.