Menu
I am confused. Maybe you can help me :)
I have been following the guidance of CAG and found the MVP pattern very natural to me. Suppose I have a UI-ready Model (for example : implements INotifyPropertyChanged), I use the presenter to bind this Model to a view (presenter knows an interface of the view), keeping my Code-Behind as small as possible handling only Bindings (Model and Commands) properties (or methods) or events for controls that don't have ICommand and in this case immediately being delegated to the presenter.
After a while I've discovered the MVVM pattern, and so far it eludes me. As far as I can tell in my approach I would use MVVM only when my Model is not UI-ready. But would it be more reasonable to keep the presenter and just use a new Model, I fail to understand what do I lose with this kind of usage. I know I am missing something, but what is it :).
Also when your View is generic and can handle many kinds of Models (such as in a PropertyGrid). ViewModel is recommended to be used with a DataTemplate, but in this case you just can't create a Template for each entity in your Model, it is just need to be investigated in runtime, what would you recommend?
While watching Josh Smith talking about MVVM in a screencast, I got a feeling that the re exposing of the Model in the ViewModel is violating DRY (do not repeat yourself), is it really unavoidable? it surprises me nobody his arguing about it in comparison for the flames ADO.Net Dynamic Data metadata classes are getting nowadays.
Hope it was clear enough
Thanks
Ariel
429
MVVM is better than MVC/MVP because of its unidirectional data and dependency flow. Dependency is one way, thus it is a lot easier to decouple it when we need to. It is also easier for testing. All my projects(written in Kotlin for Android app) are based on MVVM.
Benefits. MVVM has resolved the issue of tight coupling which is facing in MVP(One-to-One), In the MVVM(One-to-Many) View keep reference to ViewModel and ViewModel don't have any knowledge about View.
References — In MVC, the View doesn't have reference to the Controller while in MVP, the View has reference to the presenter and in MVVM, the View has reference to the View-Model. Entry Point — For MVC, the entry point to the application is the Controller whereas, for MVP and MVVM, the entry point is the View.
The Windows Presentation Framework (WPF) takes full advantage of the Model-View-ViewModel (MVVM) pattern. Though it is possible to create WPF applications without using the MVVM pattern, a little investment in learning can make building WPF applications much simpler.
Regarding #3, a lot of people will use the "another layer of indirection" argument, saying that changes in the model won't affect the view. While this is technically correct, it's not the real reason to do something like this.
If you consider the Model as the entities you get back from, say, a data access layer or a service (which is what these are generally considered) you begin to see why you need a ViewModel. A ViewModel is designed to extend the model with behaviors the View needs.
For example. If you want to be able to change a property and have the View notified of this change through binding, the property needs to raise some form of NotifyPropertyChanged so that the view can react. This is behavior that your typical model won't have.
In another example, let's say you have a collection and you'd like to flag each item in the collection with a boolean value when a user clicks a checkmark next to that item in the view. You'd need an "IsSelected" property, probably. This is a behavior that the Model shouldn't have to provide.
However I see where you are coming from... I definitely had a problem with this at first. The first time I copy and pasted the contents of a model into my viewmodel, my stomach turned, but you just have to make peace with the fact that for your View to work, it's going to need this extra bit of behavior that a Model shouldn't provide.
No matter how un-DRY this is, forcing your WCF types or LINQ to SQL types (or whatever your favorite ORM is) to implement INotifyProperyChanged is worse.
69
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
