MVVM (Model View ViewModel) Introduction: Part 1

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