MVVM design pattern is specifically for WPF or Silverlight applications because of the built in support provided by the dependency objects. If you are looking for similar design pattern for winforms, then take a look MVP-VM design pattern which is similar to MVVM but suitable for winforms application.
MVVM, MVP, MVC, MVP-VP all of these design patterns are basically designed to implement separation of concerns. That means, separate the functionalities into multiple layers and each layer will have its own responsibility. In MVVM design pattern M, V, VM each has its own responsibility.
M – Model: Model has different meaning based on the context. Model can be a domain model or a model which is used to communicate to database. We will consider the model as a business entity. All business logics will go into the model. (You can have more segregated layers in the Model)
V- View: View is simply WPF screen and its code behind. Its responsibility is to get the user inputs or show information from the repository. No other complicated logic will be written in view.
VM-View Model: This one is a new layer came with the MVVM design pattern. View model is a model (of course different from Domain Model, in our case business entity) which is used to get data from Model object and do manipulation on the data in such a way the View will be expecting. In most of the scenario, we cannot retrieve the data from Model object and directly display in the View .So we will implement that kind of manipulation in view model and ViewModel should only be used in View layer.
General Rule in MVVM:
In this design pattern, the communication between the M,V,VM is very important to understand.
View may or may not have reference about ViewModel.
Same like that ViewModel may or may not have reference of View. Sometime, both may not have reference to each as direct reference. But they may be using some interface.
But, at any situation, View should never have reference of Model. Also, Model should not have reference of View. That means, both must not know about each other.
Both View and Model will be communicating between each other through ViewModel only. Below image will help you understand in clear.
I really want keep the example very simple. So, we have “Register” screen with FirstName, LastName of the customer. When we click Submit button, that calls data access layer to save the customer. Second screen is “CustomerDetail” that displays Full name (FirstName + LastName) of the customer from repository.
Update changed from ViewModel to View:
In WPF, View and View model will be communicating between each other using events. Whenever there is a change in the property value of the ViewModel, it will raise an event to inform the Control in WPF window (ex. Textbox’s text property), that the particular property has been changed. Then the control will display the changed value.
When I say WPF controls listen to an event it will be listening to a very particular event called “PropertyChanged” event. But how? WPF is full of Dependency Object. Most of the properties of WPF controls are Dependency object. Ex. Text property of the Textbox. Dependency object provides many built in functionalities. One of the features is to automatically listen to “PropertyChanged” event from the property which is Bind with the control’s property. To implement this Property Changed event, .Net framework has given one interface called “INotifyPropertyChanged” interface. This Interface has abstraction of “PropertyChanged” event. So, if you want your ViewModel to update the changes to the View, then ViewModel must implement “INotifyPropertyChanged” event.
You may have a question that, if we need to bind FirstName and LastName property, where these 2 properties to be defined? Whether we want to have these properties in ViewModel? Or Model or in Both? Because the same 2 properties may need to be in Model also, if our business logic is using FirstName and LastName. Because Model is what going to be used in all other layers. If that is the case, then we will have duplicate copy, because same will be in ViewModel as well as Model.
How do solve this? Well, we will have these 2 properties in Model and have a property in ViewModel which is of type Model. In that case, Both ViewModel and Model at the minimum, must implement “INotifyPropertyChanged” interface. So, our Textboxes will be bound with the property in ViewModel , which internally uses the property in the Model. So, whenever the value of the property in Model got changed, will be directly notified to View.
Update changes from View To ViewModel:
Same like this, whenever there is a change in WPF Controls and if you want to update that value to the Property in ViewModel, then we need to use “UpdateSourceTrigger” property which is in the “Binding “ class. Without using this property, if the user enter value in the textbox, that will not be reflected in to the property in the Model through ViewModel.
Button Click Event:
One other thing to know is, WPF has the concept called Routed Events and Command. Commands are used to do some action when the button clicked. We will a separate class to implement another interface called “ICommand”. Once we implement, that particular class type will used as a property in the ViewModel. The constructor of the Command class will be accepting an “Action” which is going to be the method in ViewModel. Then Command Property will be Bind with the Button Command in View.
Since the answer box does not accept this big answer, I have posted the sample code as second answers.