MVVM standardization [modified]
-
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
-
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
Michael Sync wrote:
Do you think that it's okay for ViewModel have the interface of View
There is one simple reason why I think that it's okay for the VM to have a reference to the interface for the view.... I do not know of any reason why it is forbidden.... it's not like you are directly referencing a View.... it's an interface that the view happens to implement. Many views can implement the same interface so you are not tying the VM to a particular view.
Why is common sense not common? Never argue with an idiot. They will drag you down to their level where they are an expert. Sometimes it takes a lot of work to be lazy Individuality is fine, as long as we do it together - F. Burns Help humanity, join the CodeProject grid computing team here