问题
I don't think I understand the MVVM pattern properly because having a Model and ViewModel class seems redundant to me.
My understanding of the Model is to basically add in minor details of a class and let the ViewModel handle all the logic and implementation. If that is the case why separate the two? Couldn't you create the variables, properties and such in the view model and still have the logic in there?
To me it sounds like C++ in a way. You have the header file which describes the class and the implementation file which defines the class. Is there any point to doing it this way in c#?
I feel like I don't understand the separation because I don't fully understand the MVVM pattern. If someone can clarify it for me that would be awesome.
Thanks in advance.
回答1:
To try and make this a more tangible answer , lets look at an example. You want to have the same old "calculator" example in a nice shinny WPF program.
Instead of jumping in and writing everything in the view model, you remember that you actually wrote this ages ago for a different project, and you actually were smart enough to have all the calculator functionality in a separate (and reusable) dll.
So, you got your model.
Now all that's left is your GUI. You draw a nice shiny window in WPF (View) , and then you need to bridge your calls and data from the dll to the view. You guessed right ... this is your ViewModel :).
On another note, the idea is to be able to work on a big team where some people work on the logic (model), some designers work on the view, and someone else (can be any of the above ofcourse) can get the bits working together with the view models.
回答2:
The models represent your data. The viewmodel only uses those models to drive your UI. Models should represent entities... things. Viewmodels use those things, that's the difference.
回答3:
The problem is that user interfaces themselves can get pretty complex. You've got widgets all over the place - sliders, text fields, buttons, checkboxes, radio buttons - and sometimes there's more to the View than just "fill in these blanks with these values from the Model". The ViewModel is a model of your data from the UI's standpoint. Usually this is a simplification of the full view, but it could also be a complication (if you have an aggregate field built up from multiple controls stored in a single attribute in the persistent store, for instance).
回答4:
One more simple example. In the current Distributed Architecture it is not necessary that your database(Model) and the business logic(VM) are designed on the same physical system. So it is possible that the data(Model) is exposed by some service (like WCF or WebApi) which can then be easily consumed by the VM (by adding the respective dll in your project).
One more important point is that it is not necessary that you would display each and every column of the table in your database on the UI. So by having a Model the VM would only get the relevant data which is necessary for the end user on the UI.
来源：https://stackoverflow.com/questions/25336697/whats-the-point-of-separating-the-model-from-the-view-model-mvvm