Model/View/ViewModel (MVVM) Pattern and Windows Presentation Layer(WPF)

Model/View/ViewModel (MVVM) is a variation of Model/View/Controller (MVC) that is tailored for modern UI development platforms where the View is the responsibility of a designer rather than a classic developer. The designer is generally a more graphical, artistic focused person, and does less classic coding than a traditional developer. The design is almost always done in a declarative form like HTML or XAML. In short, the UI part of the application is being developed using different tools, languages and by a different person than is the business logic or data backend.


Gossman’s MVVM is identical to Fowler's Presentation Model(PM), in that both patterns feature an abstraction of a View, which contains a View's state and behavior. Fowler introduced Presentation Model as a means of creating a UI platform-independent abstraction of a View, whereas Gossman introduced MVVM as a standardized way to leverage core features of WPF to simplify the creation of user interfaces. In that sense, I consider MVVM to be a specialization of the more general PM pattern, tailor-made for the WPF and Silverlight platforms. Model/View/ViewModel also relies on one more thing: a general mechanism for data binding.


The Model is defined as in MVC; it is the data or business logic, completely UI independent, that stores the state and does the processing of the problem domain. The Model is written in code or is represented by pure data encoded in relational tables or XML. The View in Model/View/ViewModel consists of the visual elements, the buttons, windows, graphics and more complex controls of a GUI. It encodes the keyboard shortcuts and the controls themselves manage the interaction with the input devices that is the responsibility of Controller in MVC. The View is almost always defined declaratively, very often with a tool. By the nature of these tools and declarative languages some view state that MVC encodes in its View classes is not easy to represent. At this point data binding comes into play. In simple examples, the View is data bound directly to the Model. Parts of the Model are simply displayed in the view by one-way data binding. Other parts of the model can be edited by directly binding controls two-way to the data. For example, a boolean in the Model can be data bound to a CheckBox, or a string field to a TextBox.


In practice however, only a small subset of application UI can be data bound directly to the Model, especially if the Model is a pre-existing class or data schema over which the application developer has no control. The Model is very likely to have data types that cannot be mapped directly to controls. The UI may want to perform complex operations that must be implemented in code which doesn't make sense in our strict definition of the View but are too specific to be included in the Model (or didn't come with the pre-existing model). Finally we need a place to put view state such as selection or modes.


The ViewModel is responsible for these tasks. The term means "Model of a View", and can be thought of as abstraction of the view, but it also provides a specialization of the Model that the View can use for data-binding. In this latter role the ViewModel contains data-transformers that convert Model types into View types, and it contains Commands the View can use to interact with the Model.


WPF & XAML Data Binding

Basic Data Binding Concepts :

• Direction of the Data Flow
• What Triggers Source Updates

Regardless of what element you are binding and the nature of your data source, each binding always follows the model illustrated by the following figure:

As illustrated by the above figure, data binding is essentially the bridge between your binding target and your binding source. The figure demonstrates the following fundamental WPF data binding concepts:

• Typically, each binding has these four components: a binding target object, a target property, a binding source, and a path to the value in the binding source to use. For example, if you want to bind the content of a TextBox to the Name property of an Employee object, your target object is the TextBox, the target property is the Text property, the value to use is Name, and the source object is the Employeeobject.
• The target property must be a dependency property. Most UIElement properties are dependency properties and most dependency properties, except read-only ones, support data binding by default. (Only DependencyObject types can define dependency properties and all UIElements derive from DependencyObject.)
• Although not specified in the figure, it should be noted that the binding source object is not restricted to being a custom CLR object. WPF data binding supports data in the form of CLR objects and XML. To provide some examples, your binding source may be a UIElement, any list object, a CLR object that is associated with ADO.NET data or Web Services, or an XmlNode that contains your XML data. For more information, see Binding Sources Overview.

• OneWay binding causes changes to the source property to automatically update the target property, but changes to the target property are not propagated back to the source property. This type of binding is appropriate if the control being bound is implicitly read-only. For instance, you may bind to a source such as a stock ticker or perhaps your target property has no control interface provided for making changes, such as a data-bound background color of a table. If there is no need to monitor the changes of the target property, using theOneWay binding mode avoids the overhead of the TwoWay binding mode.
• TwoWay binding causes changes to either the source property or the target property to automatically update the other. This type of binding is appropriate for editable forms or other fully-interactive UI scenarios. Most properties default to OneWay binding, but some dependency properties (typically properties of user-editable controls such as the Text property of TextBox and the IsChecked property of CheckBox) default to TwoWay binding. A programmatic way to determine whether a dependency property binds one-way or two-way by default is to get the property metadata of the property using GetMetadata and then check the Boolean value of the BindsTwoWayByDefault property.
• OneWayToSource is the reverse of OneWay binding; it updates the source property when the target property changes. One example scenario is if you only need to re-evaluate the source value from the UI.
• Not illustrated in the figure is OneTime binding, which causes the source property to initialize the target property, but subsequent changes do not propagate. This means that if the data context undergoes a change or the object in the data context changes, then the change is reflected in the target property. This type of binding is appropriate if you are using data where either a snapshot of the current state is appropriate to use or the data is truly static. This type of binding is also useful if you want to initialize your target property with some value from a source property and the data context is not known in advance. This is essentially a simpler form of OneWay binding that provides better performance in cases where the source value does not change.

Note that to detect source changes (applicable to OneWay and TwoWay bindings), the source must implement a suitable property change notification mechanism such as INotifyPropertyChanged. See How to: Implement Property Change Notification for an example of an INotifyPropertyChanged implementation.

The Mode property page provides more information about binding modes and an example of how to specify the direction of a binding.

Tips:
1. We can access a Singleton Object through XAML(which is equivalent to accessing Static Member of the Class) using x:Static XAML Markup Extension.


2. We can accesss a Constructor with Parameters using ObjectdataProvider.ObjectDataProvider (ODP) acts as a wrapper around your CLR object and helps in the data-binding. There are couple of ways of creating the ObjectDataProvider. Beatriz Costa did a great post on this topic, so I am not going over those details. Interestingly there is one more way of creating the ObjectDataProvider, which is just an extension of using the MethodName property.




Data Binding ref:

http://social.msdn.microsoft.com/forums/en-US/wpf/thread/7416d552-b766-4bd2-b33c-2bf454dca8dd


http://pavanpodila.spaces.live.com/blog/cns!9C9E888164859398!301.entry


http://www.beacosta.com/blog/?p=22


http://msdn.microsoft.com/en-us/library/ms752347.aspx


http://msdn.microsoft.com/en-us/magazine/cc163299.aspx


http://www.beacosta.com/blog/?p=22


http://coredotnet.blogspot.com/2006/05/wpf-data-binding-tutorial.html

http://blogs.microsoft.co.il/blogs/dorony/archive/2007/08/31/WPF-Binding_2C00_-INotifyPropertyChanged-and-Linq.aspx

http://blogs.microsoft.co.il/blogs/davids/archive/2009/05/19/staticresource-and-dynamicresource.aspx


MVVM ref:

John Gossman's observations on MVVM -

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


The Model-View-Presenter-ViewModel(MVPVM) Design Pattern for WPF - http://msdn.microsoft.com/en-us/magazine/hh580734.aspx


WPF Apps With The Model-View-ViewModel Design Pattern -

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx


Prism: Patterns for Building Composite Applications with WPF -

http://msdn.microsoft.com/magazine/cc785479


Model View Presenter by Jean-Paul Boodhoo -

http://msdn.microsoft.com/en-us/magazine/cc188690.aspx


Customize Data Display with Data Binding and WPF -

http://msdn.microsoft.com/en-us/magazine/cc700358.aspx


Patterns For Building Composite Applications With WPF -

http://msdn.microsoft.com/en-us/magazine/cc785479.aspx


The Command Pattern In Windows Presentation Foundation -

http://www.microsoft.com/belux/msdn/nl/community/columns/jdruyts/wpf_commandpattern.mspx

http://consultingblogs.emc.com/richardgriffin/archive/2007/02/23/WPF-Commands-a-scenic-tour-part-I.aspx


Understanding Routed Events and Commands In WPF -

http://msdn.microsoft.com/en-us/magazine/cc785480.aspx


WPF & ICommand -

http://msdn.microsoft.com/en-us/library/ms752308.aspx


Use Design Patterns to Simplify the Relationship Between Menus and Form Elements in .NET

http://msdn.microsoft.com/en-us/magazine/cc188928.aspx


INotifyPropertyChanged and WPF- http://japikse.blogspot.com/2009/07/inotifypropertychanged-and-wpf.html