Menu
I have read the MSDN article on MVVM and I am not really convinced. If the model already implements INotifyPropertyChanged/INotifyCollectionChanged, what's wrong with the View binding directly against the Model? It seems the extra ModelView introduces some code without much benefit. Am I missing something?
223
MVVM creator John Gossman points out that implementing MVVM is "overkill" for simple UI operations, and that for larger applications, generalizing the ViewModel becomes more difficult.
MVVM works well if your app requires many model-to-view transformations. However, not every object will neatly fit into the categories of model, view or view model. Instead, you should use MVVM in combination with other design patterns. Furthermore, MVVM may not be very useful when you first create your application.
Disadvantages of MVVM Model:This can confuse the developer and make the development or debugging process complicated. When it comes to an Android environment, the user is restricted with only two ways to work with View. Moreover, they can either use Data Binding or any other View method.
Because a view model doesn't have a reference to the object it is owned by, it easy to write unit tests for a view model. Another, and often overlooked, benefit of MVVM is improved testability of view controllers. The view controller no longer depends on the model layer, which makes them easier to test.
I was also a bit skeptical about MVVM until I watched this great presentation by Jason Dolinger. I recommend all my co-workers who are starting out in WPF and MVVM to watch it.
Jason started with an application that one would write in a “traditional” way, with button clicks handled by event-handlers in the code-behind that then updated other parts of the UI. Using WPF data-binding, Commands, and Unity, he transformed it, piece by piece, in a much more manageable, encapsulated, readable, and testable M-V-VM design. It was awesome.
To answer your question more directly, even if it seems silly to bind to a ViewModel when your Model already has everything, you'll often wind up needing one little adjustment to the Model that's needed only by the View. Over time, these little changes will creep into your Models, where they don't belong. It'll make your models more complicated than they ought to be.
What I often do when I have a Model that "has it all", is I add a ViewModel that contains one property, the Model. Then in my bindings I just bind to Model.Name, Model.Age, etc. It's really no effort. Later on, if I need tweaks only for the View, I already have my ViewModel class ready. This also makes your code more intuitive and easier to understand. You won't wonder, did I bind to the Model or the ViewModel in this case? It will always be the ViewModel.
157
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
