MVVM standardization

Feb 8, 2010 at 9:00 AM

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.

What do you think about that?

Again, I totally understand that we can combine the patterns or modify the pattern or even create our own pattern based on your project's need and to make developer's life easier.

But if we are using MVVM then everyone should have same understanding about what we should/shouldn't do in MVVM . 

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.

Feb 8, 2010 at 11:28 AM
Edited Feb 8, 2010 at 11:31 AM

You need to be careful with "ViewModel rarely needs to be changed to support changes to the view".

Since the ViewModel is tailored to fit the needs of the View it is actually quite often that you need to modify the ViewModel to make changes to the View. Going with YAGNI, the ViewModel usually just exposes as little as possible just to satisfy the current requirements for the View. If those requirements change, the ViewModel often needs to change with it.

If I decide, I would like to see the customer's phone number in the View too, I need to get it from the Model and expose it in the ViewModel first. Or if I decipe I would like to be able to split the Display of the customers Adress into separate fields with labels for Street, City etc. the Adress property in the ViewModel can't be a single string anymore.

It is understood that the ViewModel usually does not have to change for cosmetic purposes or lust to to support a different look and feel, but beyond that changing the ViewModel for the View is quite common.

Feb 8, 2010 at 11:36 AM

>>If I decide, I would like to see the customer's phone number in the View too, I need to get it from the Model and expose it in the ViewModel first. Or if I decipe I would like to be able to split the Display of the customers Adress into separate fields with labels for Street, City etc. the Adress property in the ViewModel can't be a single string anymore

>>It is understood that the ViewModel usually does not have to change for cosmetic purposes or to  just to support a different look and feel, but beyond that changing the ViewModel for the View is quite common

yes. you are right. I was talking about that one.. We normally need to change look and feel only because the base layer is already designed when we are getting the requirement. But if there are very big changes then ViewModel will have to change. even Model will have to change.. 

I will add it as a note in my list.. Thanks a lot for your suggestion..