In MVVM there can be only one View for each one View Model?

As I read here:

http://msdn.microsoft.com/en-us/library/gg405484(v=pandp.40).aspx

There is typically a one-to-one relationship between a view开发者_如何学编程 and its view model.

It means that by design they don't really cope with multiple views ?

I think this is usually the case in practice. However, the beauty of separating the presentation into a View and a ViewModel means that you could easily create many different Views, each showing basically the same data from the Model, all sharing the same ViewModel class (maybe or maybe not the same instance). For example, I could have a simple and advanced View of my data, written mostly in XAML as two completely different UserControl's, both sharing the same ViewModel (class or maybe instance). Without using MVVM this would be trickier to do without duplicating code.

I think there is no restriction of this, it totally depends on your design and requirement. You can create multiple View for a single ViewModel to present different UI representation.

In MVVM, you have a View (presentation) and a ViewModel (logic) which is intended to support that presentations needs. You can easily have multiple views for a ViewModel, and often this is expected, mostly in the case where you have multiple DataTemplate objects (which is a view) bound to a single ViewModel type based on the context in which it is being used.

While there is typically a one to one mapping of these, this is not a limitation but a convention and there is no "design limitation" in the MVVM pattern.

Correct. Typically, view model is designed specifically for one view. It doesn't have any knowledge about specific controls used in the view, but it does have the structural and functional knowledge. Having multiple views and one view model would often make the view model class violate the single responsibility principle.

Although, sometimes it does make sense to have several views and one view model. For instance, basic and advanced version of the same view. In basic version you just hide some parts or present the information in a simpler way with simplified functionality. In this case it is absolutely OK to have one view model for those two views because otherwise you would have to duplicate most of the view model's code.

The MVVM pattern doesn't enforce the one-to-one relationship between view and view model, but in most cases it is the recommended approach. And if you want to have multiple views for one view model you should think carefully before going that path because you might end up with a view model which has half of its members used by one view and the other half by another.

I actually used the fact that this one-to-one relationship is not enforced in a project.

We had an alerts vm, and we wanted to show them in a list on one of our views, but than also popup a notification when there's a new alarm and do it in the main screen. By setting the data context of the popup control to the alarms vm, we could easily achieve this functionality.