MVVM (Model View ViewModel) Introduction: Part 1

Introduction
 
In this article I'll talk about how to enhance WPF, Silverlight and Windows Phone application productivity, maintainability and testability with some UI-based Design Patterns. As you know, a Design Pattern is a collection of guidelines that help us build applications more efficiently. In the traditional approach, we encounter many problems every day related to the data access layer, business layer and always the user interface.

Time is changing and the customer wants his application to have even more new functionality, features as well as a good user interface, and the manager wants to deliver the product in less time and using fewer resources. Instead of separate testers, all testing should be done by the programmer only. Such a problem can be solved by a UI based Design Pattern that can reduce the pressure on the developer. You can say that a UI based design helps us to improve application productivity, maintainability, flexibility, testability and reusability. It helps us as a designer, developer and a tester. The developer and designer can work together on the same project without interrupting each other and unit test can happily be done by the programmer, not by separate  tester guys  for unit testing .
 
Model View View-Model (MVVM) is basically a UI Based Design Pattern. The main object of MVVM is to provide a rich UI, testability features, code more reusability and complex data binding. It helps to improve the separation the of the business and presentation layers without any direct communication between each other. The designer and developer can work together without interrupting each other. Easy testability and maintainability is also popular in MVVM Design Pattern. This is the power the full Design Pattern for WPF, Silverlight, Windows Phone and Surface applications and now is the time for people to also use it with HTML5 and web-based technology. It's very similar to MVC and MVP Design Patterns. In this article I'll explore the MVVM Design Pattern and the basics of MVC and MVP .
 
In sort these three are look like MV(C-P-VM) Most of beaver is also over all same.

• Model: Data, entity, ORM.

• View: Presentation Layer, User Interface.

• Presenter or Controller or ViewModel: Business Object, Business Layer.

Model View controller (MVC)
Model View Presenter (MVP)
Model View View-Model (MVVM)
 
These are all Design Patterns with the same goals but differing solutions.

The strengths of these Design Patterns are:

• Rich UI
• Testability
• Modularity
• Maintainability
• Flexibility

Model View Controller (MVC)

• First described in 1979 for Smalltalk at Xerox PARC
• The Controller is the centerpiece that decouples the Model  and View.
• User interaction event
• The Controller handles events and converts them to a user action that the Model can understand
• The Model manages the behavior and data of the application domain
• The View interacts with the Controller and the Model to generate a user interface

More about MVC: http://msdn.microsoft.com/en-us/library/dd394709(v=vs.90).aspx

Model-View-Presenter (MVP)

• MVP originated in early 1990s
• MVP is a derivative of MVC
• Two types of implementation
• ive View
• Supervising Controller
• Presenter assumes the functionality of the MVC Controller
• The View is responsible for handling UI events
• The Model becomes strictly a Domain Model
• It is more User Interface centric

More about MVP: http://msdn.microsoft.com/en-us/library/ff647543.aspx

 MVVM (Model View ViewModel)

History Of MVVM

MVVM was introduced by John Gossman in 2005 specifically for use with WPF as a concrete application of Martin Fowler's broader Presentation Model pattern. The implementation of an application, based on the MVVM patterns, uses various platform capabilities that are available in some form for WPF, Silverlight Desktop/web, and on Windows. Many commercial applications, including Microsoft Expression products, were built following MVVM.

More about. http://blogs.msdn.com/b/johngossman/archive/2005/10/08/478683.aspx

Advantage of MVVM

• Modularity
• Test driven approach.
• Separation UI and Business  layer as view and view model.
• Code sharing between pages and forms.
• Easy to Maintain.

More MVVM advantage and disadvantages:

http://blogs.msdn.com/b/johngossman/archive/2006/03/04/543695.aspx

List of features of MVVM

• It separates the business and presentation layers, like MVP and MVC.
• Improve Structure/separation of concerns (View, ViewModel and Model).
• Enable a better Design/Developer Workflow.
• Enhance simplicity and testability.
• Enabled by the robust data binding capability of XAML.
• No need to use a code behind file (minimalist code-behind file).
• Provides application development ability for multiple environments.
• Powerful Data Binding, command, validation and much more.
• The designer and developer can work together.

Why MVVM?

• No direct communication between View and ViewModel, only the ViewModel is aware of the needs of the View.
• It makes code more maintainable, and will help it last longer.
• Reusability, assuming we have one WPF application with code and now we want the same business logic in a Windows Phone or Silverlight then that could be quite a bit of hard work.

But if your application uses MVVM Design Patterns then this work 'll be easy.

• Avoids duplicated code to update views.
• Unit testable.
• You can use a "ViewModel" to aggregate parts of your model that exist in separate classes/libraries to facilitate a more fluent interface for the "view" to deal with.
• Powerful Data-binding support with INotifyPropertyChanged, ICommand and IvalueConverters.
• Easy refactoring.
• MVVM is best for WPF, Silverlight, Windows Phone and Surface applications.
• Extensibility.

MVVM Principles:
 
The Simplicity Principle: 

Each View should have a single ViewModel and a ViewModel should only service a single View.

The Blendability Principle:

The ViewModel should support Expression Blend.

The Designability Principle:

The ViewModel should supply Design Time Data.

The Testability Principle:

The ViewModel and Models should be testable.

For more details http://practicalmvvm.com/Manifesto/

MVVM Architecture


 
In the above I try to show the Model-View-ViewModel architecture, view ing commands and data in a ViewModel, the view can also bind data in two ways and base the data from the view, the ViewModel sends a notification to the view. I'll explore notification and command more in the next part of this series . Unit testing is connected to the ViewModel. See in this diagram the ViewModel is the "Glue" connected to the view as well as the model and the unit test class also. The ViewModel is aware of all the properties of the method of the Model and it is also aware of the needs of the View.
 
View in MVVM

The View is the client interface, input-output interface or the user interface. It collects all the user interface elements of the window, navigation page, user control, resource file, style and themes, custom tools and controls. The view is unaware of the ViewModel  and the Model, and vice versa the ViewModel and Model is unaware of the View and control is tightly decoupled.

 But the view model is aware of the needs of the view. They communicate by data binding and a dependency property or properties.

Communication between the view and view model occurs by the DataContext property. Code behind the view only contains a constructor that calls an InitializeComponent method and in some cases people use a UI logic event here, visual and logical tree code implementation and custom logic property. But that's not good in the MVVM Design Pattern, because we create unit testing on the ViewModel and a parameter through the view model. In this case the view code behind logic and data will not be tested and you need to again test the code behind page. One view can only communicate with a single view-model at a time.

ViewModel in MVVM

ViewModel is a non-visual class. The MVVM Design Pattern does not derive from any WPF or Silverlight based class. The ViewModel is unaware of the view directly. Communication between the View and ViewModel is through some property and binding. Models are connected directly to the ViewModel and invoke a method by the model class, it knows what the model has, like properties, methods etcetera and also is aware of what the view needs.

One View-Model can connect to multiple models, work like a one-to-many relationship and encapsulate business logic and data for the View. A ViewModel inherits some interface like INotifyPropertyChanged, icommand INotifyCollectionChanged etcetera.

Model in MVVM

The Model represents your data, like employee, product or customer. Generally define a set of properties and methods. You might create a model from scratch or get it from an ORM like Entity Framework or from some server proxy. The Model is responsible for managing the application data and for ensuring its consistency and validity by encapsulating the required business logic and data validation. Accessing a model instance by querying a database and create an instance in a loop or using WCF, asmx or REST.

Depending on your business requirements, call a method to retrieve a single or a collection of instances. The Model classes typically provide data validation and error reporting through either the IDataErrorInfo or INotifyDataErrorInfo interfaces.