With MVVM, does each UI window have its own ViewModel?

Question

When I\'m designing multiple views under the MVVM pattern, does each view get its own ViewModel or do they all share the same one? I understand that this is ultimately a flexib

Answer 1

Yup, each view should have its on ViewModel.

I don't know WPF inside out, but generally the ViewModel mediates between a UI component and a business logic component. In other words: It's specific to a view/model pair - this is the only reason for this component to exist...

HTH.

Answer 2

To me thats a subjective statement- text book, I would say definately a 1-1 pairing - and there is certainly nothing wrong w/ being proactive and setting the paradigm by having a 1-1. However, if you have multiple views each representing a slice of the same data you dont necessarily have to have 1 per- you could reuse the same one across multiple views until you had a deviation. The purpose of the view model being a bridge between the ui and the business layer...if the business functions are the same you are either going to have a common view model interface or base and cast down or you are going to be replicating the same logic multiple times. If the view is the only thing that changes I see no issue in reusing the same view model until there is deviation.

In wpf, you should be binding to values on the model so unless your view model has a reference to your concrete view that shouldnt be an issue. Even it does, you could abstract out to a view contract (interface) and change the property to be that type instead.

Answer 3

Yes, basically the idea is that your viewModel should only be used by one view. If you use a viewModel to populate an area (like in ASP.NET MVC) then that viewModel is "reused" each time that view is presented in difference places.

This article is a discussion by Josh Smith of the MVVM pattern. Then, Ward Bell discusses in this article what he thinks Josh left out, while maintaining that Josh's work is still very strong.

Ward does an excellent job of laying out the complexities of this pattern and showing the tension that exists. Here is his take on the tension:

In my experience there is a “dialog” between View and ViewModel design. The VM exists to serve a view even as it strives for independence from any particular concrete view. A VM is useless if there is no view that will work with it; clearly the VM developer must heed the imprecations of the View developer.

On the other hand, in business applications the application’s imperatives – what the view must do to satisfy business requirements – are the province of the programmer and are > best articulated through the capabilities of the ViewModel.

Therein lies the necessary tension between View and ViewModel design. As a developer my allegiance is with the ViewModel (“the application should do something worthwhile”) but it would be silly to defend that allegiance at the expense of the View (“a good UX is essential to making an application easy to learn and to use”).