Rules of MVVM??

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.

Goals

• 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 user 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
• 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.