MVVM standardization

Someone in Silverlight posted that MVVM currently lacks standardization so that everyone has own flavor..

That's why me and a few guys from WPF Disciples are actively discussing which elements of 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 driv开发者_C百科en 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

1. INPC / Property binding
2. Events
3. Messages (Event Aggregator/Messenger/RX framework)
4. Through an intermediary such as a service
5. Through an interface
6. 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.

---

I like what you have written. One of the things that really bugs me is that a lot of people seem to have their VM coupled very tightly to their View - if you are doing this then you might as well just be doing the old XAML + everything whacked into the code behind thing.

The pattern I use is a slight variant on the MVVM (but it is mostly the same). Personally I like to have my ViewModel given to the View as an interface - it keeps the separation very clean. This has a lot of benefit when doing prototypes, visual elements can be switched in or out of the View with little or no impact on the ViewModel.

---

I think the communication between View ViewModel via databinding is what makes MVVM it's own pattern as opposed to other separation of concerns. It isn't so much whether it whether its GOOD or BAD for the vm to know about the view via interface, but in the context of communicating the pattern being used it is not MVVM.

Some of the difficulty in getting and maintaining standards lies in the shortcomings and complexity of WPF and Silverlight, sadly. When there are multiple valid standards however, I would put on my Martin Fowler hat and add a "when to use it" section.

Do your standards cover cross-cutting concerns like localization?

FWIW I like the content of what you wrote and am glad you posted it here...

Cheers,
Berryl