Answers to Basic WPF-MVVM Questions

Introduction 

 
This article attempts to provide simple answers to basic WPF and MVVM questions.
 

What is WPF?

 
Windows Presentation Foundation is a “Presentation” system for building Windows applications. If you are a WinForms developer, the major difference you can find in WPF is the way that the designer looks. Unlike in WinForms, the designer code is not C# code, but XAML code.
 

Why WPF?

 
The major reason for WPF being preferred over WinForms is that WPF provides rich UI. Apart from this, there are many other benefits that WPF provides. It is available more clearly in many tutorials on the internet. It is a vector-based rendering engine. Simply comparing the UI of a WinForms application and a WPF application will show the difference in terms of looks and feel.
 

What is MVVM?

 
MVVM is a pattern that is adapted while developing applications. The acronym stands for “Model View View Model”. Basically, while structuring the project, we have a model folder under which all the model files (.cs) would be placed, under the view model folder all the viewmodel files(.cs) would be placed and under the view folder, all the view files(.xaml) would be placed. If MVVM is used then there won’t be any code behind it. This means that .xaml.cs file would not have any code except for the auto-created method.
 
Model
 
Model has the business logic part which supports the view model with the data that would ultimately be presented in the view.
 
ViewModel
 
Every view would have a view model. Viewmodel would implement INotifyPropertyChanged Interface, and would have all the properties that are bound to the corresponding view. The view model is not loaded with any business logic and the responsibility lies with the model.
 
View
 
View is nothing, but the XAML file is where the window is designed. XAML is a markup language. In WPF, unlike in Winforms, every control would be bound with a dependency property either predefined or user-defined.
 

Why MVVM?

 
Whenever an application is being developed in WPF, MVVM comes handy with it. One of the biggest advantages of using MVVM is that it makes possible for a UI independent unit testing since there is no code-behind during unit testing, No UI related objects are required and hence 100% code coverage is possible. In a unit test, ‘commands’ (look for commands in WPF) could be passed by the user to test a particular use case.
 

Is it a mandate or an absolute necessity to go with MVVM when working with WPF?

 
I would say no, it is not mandatory to go with MVVM when working with WPF however it depends upon the requirement. One has to look into the advantage MVVM provides and then decide whether to go with it or not. MVVM adds on to the complexity during the initial days of development, but ultimately, comes with its benefits. If the complete application is in Winforms and only a small module rather than a small feature is being developed in WPF, then it would not be necessary to follow MVVM, one can easily have code behind and get the rich UI experience. Again, I would repeat that it completely depends on the type of requirement.
 

Can I have multiple view models to a single view / multiple views to a single view model?

 
This is a question for which I have not got a clear crisp answer in any .NET community. First of all, as we saw that the main intention of going with MVVM is to achieve 100% code coverage, this makes it obvious that we are going to test every viewmodel independently and hence a complete form is tested. Having this in view, it is better to go for the one view one viewmodel approach. We can always communicate between the viewmodels if there is a necessity by using MVVM Light messenger or any other means that facilitates it.
 

What is the difference between viewmodel and model?

 
This is one question that beginners would always have since they do not find much difference between the two. Here is the difference: Model is nothing but a class that has the data-methods to modify the data, which would be used in the viewmodel and ultimately is bound to the view. ViewModel just has properties that would be bound to the view. In the get or set methods, one can call a method in the model to get the data. Again, this model is for this particular view model. Now you can decide if you really need a model class, if there is no heavy business logic then you can avoid a model class and place it in the viewmodel, but the cleaner option would be to use a model class.
 

In MVVM, can I skip a view model or a model class for a view?

 
Again it depends on the requirement as earlier mentioned. If there is no heavy business logic, then you can avoid a model class and place it in the viewmodel. However, the cleaner option would be to use a model class.