Rules of MVVM??

UPDATE #2:

There is very active discussion about MVVM in WPF Disciples User Group. If you are interested then please read all posts and get invoked in discussion. Here is the link. Update: Here is another one.

As I had a MVVM session at my office, I was re-reading a few articles about MVVM. We have very interesting discussion about MVVM in WPF Disciples User Group as well. You can read that post from here.

Someone in Silverlight Forum (link) posted that ~

“There are currently three main areas of criticism regarding the MVVM pattern. The first is that MVVM currently lacks standardization from Microsoft both in implementation and in toolsets. For example, the community has some lack of clarity about where and whether to implement View logic in the View layer or the ViewModel. Given that the MVVM pattern is still relatively new, and that new tool-sets, walkthroughs, or patterns, such as Onyx, Prism, the Microsoft WPF Toolkit, Crack.net, Caliburn and MVVM Light Toolkit are being released, this problem may be solved over time. Microsoft has announced in discussion boards that the MVVM template pattern will be released in Visual Studio 2010.

The second comes from MVVM creator John Gossman himself, who points out that the overhead in implementing MVVM is “overkill” for simple UI operations. He also states that for larger applications, generalizing the View layer becomes more difficult. Moreover, he illustrates that data binding, if not managed well, can result in a considerable excess of metadata in an application. Given these limitations, MVVM may have a practical minimum and maximum size for the type of application it can support, suggesting it may not perform well with large enterprise applications.

The third is that the exercise in creating large numbers of data bindings to the ViewModel results in duplicate code and maintenance problems. Additionally, because of the nature of the semantics of data bindings, critics suggest that the ViewModel does not directly describe the View.”

So, I was thinking it would be great if John and our WPF/Silverlight community can define some simple and obvious rules for MVVM pattern.I understand that there are a lot of way to implement MVVM but at least, there are some obvious rules that everyone can follow so everyone has same understanding about that pattern.

Here are some of my thoughts about MVVM.

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

What do you think about that? Feel free to let me know if you have any comment or suggestion..  Thanks.

UPDATE:

This is the open post. I will keep on updating it based on the feedback. I’m trying to discuss about those rules in WPF Disciples User Group. I understand that there are a few people who don’t want to get invoked in this kinda discussion because it can turn into a fight. Anyway, I will try to discuss with people nicely. :) I will get the feedback several groups like SL MVP/Insiders group, Stackoverflow, Codeproject and etc.

5 thoughts on “Rules of MVVM??

  1. The rule I’ve been struggling with most is not keeping a reference to the View in the ViewModel. For instance, I have an operation whose result requires me to add additional XAML controls to the View. I haven’t figured out how to do this without directly using the View from the ViewModel.

    Any suggestions? This is a Silverlight 3 application.

  2. You can probably use the Data Template for that. Put those controls in DT.

    Let’s say you have a class called Circle. So, you can have the ObservableCollection[Circle] in VM. You have ItemControl in V and that is binded to that OC[Circle]…

    If you want to increase one circle, then you can just add new circle to OC.. then new circle control from DT will be displayed in View.

    Feel free to let me know if you are not clear with that.

  3. Thanks Michael. I think I understand your suggestion and will give it a shot in the near future. I’ll try to remember to post back here with my results.

  4. I agree with Michael about the ObservableCollection approach; however, I would like to point out that some times it is necessary to add some other ingredients for the mix, for example, creating a custom ItemsControl class that prepares the container or even returns a custom one. Similarly, sometimes it is necessary to watch out for timing: binding immediately may not be a good idea as it all happens in the UI thread, you may want to create a mechanism that delays the actual binding until after a fancy animation is over.

    If testability is key, you really want to make the separation clear and strict.

  5. Currently I am converting simple WPF application to MVVM.
    I have read the MVVM rules and confused at one rule which is “No strong or weak (via Interface) reference of View in ViewModel”.

    According to me strong reference means there should not be any object/Instance of View in ViewModel.

    But what does mean by weak (via interface) reference?

Leave a Reply

Your email address will not be published. Required fields are marked *