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 ?
While a view should only have one viewmodel, a single viewmodel might be used by multiple views (imagine a wizard, for example, that has three views but all bind to the same viewmodel that drives the process).
In android, we can use ViewModel to share data between various fragments or activities by sharing the same ViewModel among all the fragments and they can access everything defined in the ViewModel.
The view model implements properties and commands to which the view can data bind to, and notifies the view of any state changes through change notification events.
Err no - it's just convention that you have one instance, but there actually aren't any rules that you can't have multiple VM's in the XAML - the key thing to understand is that every item has it's own DataContext (that's inherited), so if you need to use a different DataContext then you just bind to the appropriate VM ...
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With