Hello,
Someone in Silverlight posted that MVVM currently lacks standardization so that everyone has own favor..
That's why Me and a few guys from WPF Disciples are actively discussing about MVVM that everyone agreed. I totally understand that we have implemented the pattern in different ways and we mixed the several patterns or create our own pattern based on our project's need or to make the developers' life easier.. But forget about those difficulties or the special need of your project. Let's discuss about the standard rules of MVVM pattern that everyone agreed. I posted some of my thoughts here as well.
Why MVVM?
- Testabiltiy ( ViewModel is easier to unit test than code-behind or event driven code)
- Clear seperation between UX designer and developer
- Increases the “Blendability” of your view
- Model never needs to be changed to support changes to the view
- ViewModel rarely needs to be changed to support changes to the view
- No duplicated code to update views
Do and Don’t in View
- shouldn’t contain any logic that you want to test : As Glenn said that MVVM is not code counting exercise, we can write code in code-behind. But you should never write any logic that you want to test. For example: If user select a country then you want to display the list of states or city in your view. This is the business requirement so you should have unit test to test this logic. So, you shouldn’t write it in code-behind.
- can be a control or Data Template
- Keep the view as simple as possible. : We can still use Data Trigger or Value Converter or Visual State or Blend Behivor in XAML with care.
- use attached property if something is not bindable :
Do and Don’t in ViewModel
- Connector between View and Model
- Keep View State, Value Conversion (You can create the data structure that you want to display in ViewModel instead of using ValueConverter. For example: You need to show the Name instead of First Name and Last name. Your Model can have First Name and Last Name but You can create Name property in ViewModel. )
- No strong or weak (via Interface) reference of View
- Make VM as testable as possible (e.g. no call to Singleton class)
- No Control related Stuff in VM ( Because if you are changing the view then you will have to change VM as well. )
Model
- can be Data Model, DTO, POCO, auto-generated proxy of domain class and UI Model based on how you want to have the separation between Domain Service and Presentation Layer
- No reference to ViewModel
Do you have any suggestion or comment for that?
We have one disagreement in our group. Some said that it's okay to have the interface of View in ViewModel. But some said that if View Model has the interface of View then it will be MVP pattern.
One of our MVVM experts say about MVVM Vs MVP
View => ViewModel
- MVVM the view is directly bound to the ViewModel and talks to the VM through databinding
- In MVP, the view is bound to a model hanging off the SupervisingController or not bound at all (passive view).
ViewModel => View
MVVM
- INPC / Property binding
- Events
- Messages (Event Aggregator/Messenger/RX framework)
- Through an intermediary such as a service
- Through an interface
- Through delegates (View passes delegates to the VM which it can use to call it back. For example VM might expose a SetActions method which the View calls passing it delegates.
MVP
In the MVP case the standard is the Presenter talks back to the view either through an interface, databinding, or through properties in the case of Passive view. With Passive View the properties are not using databinding, instead the view property getters and setters are used to directly set the control value.
What do you think about that idea?
Do you think that it's okay for ViewModel have the interface of View?
If you like to add more then you are welcome to add... :)
The whole idea about this post is to get the same understanding of MVVM pattern in Community.