Yesterday, there was an insteresting question about MVVM on StackOverflow: “How to close a View from a ViewModel ?”

Like always with WPF, there are many approaches to solve this problem.

Solution 1: give a reference to the View in the ViewModel

You need to control the View from the ViewModel ? Just gives a reference to the View in the ViewModel constructor.

1
2
3
4

public Window1()
{
  this.DataContext = new Window1ViewModel(this);
}

Unfortunatelly, this approach has several drawbacks:

• it breaks the foundamental principle of the MVVM methodology: the ViewModel should be an abstraction of the View
• it complicates the work needed to unit test your ViewModel
• it introduces high coupling between the ViewModel and the View

Solution 2: the ViewModel raises an event when it wants to close its associated View

If having a reference to the View in the ViewModel is not the right thing, why not using an event. We can add a RequestClose event in the ViewModel class and raise this event when the ViewModel wants to close its associated View.

The View, when it creates the ViewModel subscribe to the RequestClose event. In the event handler, the View is closed.

1
2
3
4
5
6
7
8

// class is omitted, only constructor is shown
public Window1()
{
  var viewmodel = new Window1ViewModel();
  viewmodel.RequestClose += (s, e) => this.Close();
 
  this.DataContext = viewmodel;
}

Solution 2, first refinement

Of course I prefer the event based solution, but we can improve it. The first refinement we can do is to make sure the event will be coherent over all our classes. To achieve this I setup an interface:

1
2
3
4

public interface IRequestCloseViewModel
{
  event EventHandler RequestClose
}

This interface is implemented by my ViewModel classes which wants to support the ability to close their associated Views.

Solution 3, second refinement

Another possible refinement is to automate the subscription of the RequestClose event in the View. To do that, I created an abstract ApplicationWindowBase class that inherits from Window. When the DataContext changes, I check if the IRequestCloseViewModel is supported by the DataContext:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public class ApplicationWindowBase : Window
{
  public ApplicationWindowBase()
  {
    this.DataContextChanged += new DependencyPropertyChangedEventHandler(this.OnDataContextChanged);
  }
 
  private void OnDataContextChanged(object sender, DependencyPropertyChangedEventArgs e)
  {
    if (e.NewValue is IRequestCloseViewModel)
    {
      // if the new datacontext supports the IRequestCloseViewModel we can use
      // the event to be notified when the associated viewmodel wants to close
      // the window
      ((IRequestCloseViewModel)e.NewValue).RequestClose += (s, e) => this.Close();
    }
  }
}

Like I said in the intro, this a very basic implementation of this concept. Many other approach exists. A good source of information is in the source code of existing MVVM frameworks.

Here is the abstract translated to english:

“Inch by inch, the WPF technology is being adopted by .Net developers as a development platform for next generation user interfaces. This changeover is taking time and complicated because WPF changes principles that are well known until now in the process of designing a user interface. The Model-View-ViewModel methodology helps formalize WPF developement by giving guidance that leads to apps cleary architectured, testable, and by optimizing the workflow between developer and designer.”

I think the best way to understand how things fit together is to explore the source code of the application.

It’s a very small demo because I wanted to demonstrate only a subset of MVVM facilities, so you’ll find:

• an easy way to work with commands in MVVM using Josh Smith RelayCommand class
• the power of the ICollectionView interface to implement navigation and search feature
• empty code-behind file for my views
• a base class for all my ViewModel objects (again, based on the work of Josh)

You can download the source code here. Enjoy

If you find yourself:

• having huge .xaml.cs code behind file
• using event handler (such as Click…) everywhere
• tweaking TreeViewItem (using ItemContainerGenerator for example) to manipulate a TreeView
• having tons of IValueConverter
• … then MVVM might come to the rescue :p

What MVVM can offer?

• a clean and well defined separation between the Model and the View
• the possibility to easily leverage the power of WPF: databinding, commands, validation, and more
• a code that is testable
• an organization that facilitate the workflow between designers and developers
• minimalist code-behind file (which leads to testable code)
• facilitate the deployment of an application in multiple environment (WPF / Silverlight)

How is that possible?

Here is a part of the introduction of John Gossman:

“In simple examples, the View is data bound directly to the Model. 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 a data types that cannot be mapped directly to controls.  Finally we need a place to put view state such as selection or modes.
The ViewModel is responsible for these tasks.  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.”

• The View has the associated ViewModel set as its DataContext so that the View can easily data bind to ViewModel properties
• The ViewModel reflects its changes to the Model by calling appropriate methods on the Model
• The ViewModel exposes ICommand that the View data bind to, in order to execute actions
• The Model signals its changes to the ViewModel by raising events

What are good resources to start working with MVVM?

• Karl Shifflett started a series about MVVM, you can find his work here.
• Karl and Josh Smith wrote a very nice application that uses MVVM pattern. Moreover the application contains also information about internalization support. Check out the CodeProject article here.
• Karl wrote an article about a very important concept: user input validation. This is the first article of his new MVVM series.
• WPF architect, John Gossman wrote a series of blog post about MVVM on his blog. An introduction to MVVM is available and a good point to start.
• Josh Smith wrote an excellent tool, Crack.Net which is built using MVVM. Crack.Net is hosted on CodePlex, and studying the source code is a very good manner to understand how stuff fits together in the MVVM world.
• Josh Smith wrote an article about applying MVVM concepts to the WPF treeview. If you must work with a complex treeview, then you MUST read this article.
• Marlon Grech wrote an article about ICollectionView. ICollectionView is a useful interface that can be used in ViewModel classes to keep track user selection

If you never heard about MVVM, or never take the time to look at it, I suggest you to take a look at some of those links. Trust me, the investisment worth it !

Karl is a WPF guru, and he just started a new series of articles on Model-View-ViewModel. Here is his own introduction: “My goal is to provide an introduction, several simple examples and progress to a series of WPF LOB scenarios where M-V-VM is used.  Scenarios like, dialog box, simple form, master – detail, complex master detail with several embedded ViewModels, etc.”

I’m sure this series will very soon become the reference to learn MVVM. His first article is about validating the user input in a concise and agile way. Right now, I can’t give more details because I just start to read the article, but I’ll try to give my feedback as soon as possible.

In my previous post, I started to write about things that I think makes WPF different. In the current project I’m working on at work, I had a good example of a new way of thinking with WPF. Todays article deals with a new WPF concept called Attached properties.

Example

Imagine you need to display a list of person (that’s very original isn’t it ?). Each person has a name, a first name, and let’s say an address. Because you want to display a list of data, you’re probably going to use a ListView.You also would like to let the user sort this list of data in the order he wants, simply by dragging and dropping items in the control.

This is a feature that is possible to implement for a ListView (by handling common Drag’n'Drop events such as DragEnter, DragOver, PreviewDrop… Basically, you can think of two ways to implement this behavior:

• 1. handle all Drag’n'Drop events in the code behind (C# file)
• 2. inherit ListView and add new features

Well, in my opinion, none of those two options are very elegant:

• The first one pollutes the code behind file with “functional” code. I prefer trying to keep the code behind file as clean as possible. Moreover, this solution doesn’t allow ANY reuse.
• The second one is maybe the first one we can think about, but… It forces to change all the ListView control to our NewListView control (which inherit ListView). I don’t like that solution that much.

What is an Attached property ?

The good news is that WPF allows you to implement this by using an alternative, an Attached property. Let’s first have a look at the definition from MSDN website:

“An attached property is a concept defined by Extensible Application Markup Language (XAML). An attached property is intended to be used as a type of global property that is settable on any object.”

Hmmm… What does that mean ? Actually, if you already played with WPF, you already encountered a lot of attached properties. For example if you add an Image in a DockPanel, you might write something like

<Image DockPanel.Dock=”Top” …/>

Have you ever thought about the DockPanel.Dock part ? It is funny because Image objects don’t have a DockPanel property. Actually all UI element that you can dock (Image, TextBlock, anything) doesn’t have a DockPanel property, so how it is possible to write that ? It is possible because the DockPanel control defines an attached property.

Attached properties as an extensibility mechanism: the Attached Behavior pattern

As the name suggests, an attached property can be attached to arbitrary object. In the previous example (with DockPanel.Dock) we use an attached property to add an attribute to an object (we add the information “I want to dock this image on the top“). What is important, is that we can also use attached properties to provide extensibility without the need for traditional inheritance.

A very nice definition of the Attached Behavior can be found on the blog of John Gossman:

“The Attached Behavior pattern encapsulates “behavior” (usually user interactivity) into a class outside the visual heirarchy and allows it to be applied to a visual element by setting an attached property and hooking various events on the visual element.”

How does that work ? Basically what we can do is the following:

• Declare a boolean attached property in a new class, for example DragDropHelper.cs
• When the value of this attached property, it is possible to hook the interesting events (OnDrag, OnDrop…) and implement Drag’n'Drop operation in them

I suggest you to have a look at this excellent post from Beatriz Costa which implement Drag’n'Drop using attached properties.

The benefits of this technique are the following:

• No need to change all your ListView control to a subclass that you would create by using standard inheritance principle
• It becomes possible (as in Beatriz Costa post) to implement the Drag’n'Drop behaviour on the mode generic ItemsControl class

There are plenty of things that can be achieved using attached properties. In this post, I talked about implementing Drag’n'Drop using an attached property, but a lot of things that could be done using inheritance can be done using attached properties.

“When I installed VS.net express 2008, I was happy because I thought that with WPF I’ll be able to build nice UI. Unfortunately, I have the felling this is more like a source of problems… I spent several hours to fill a ListView with some data and the result is dirtier than with WinForms. The designer in VS.net sucks and  many controls are missing. It was so simple before…”

I wanted to give my point of view about that kind of reasoning because a couple of months ago, I think I had more or less the same… So, what makes WPF so different ? Or why I cannot just use my WinForms background and start to build wonderfull apps ?

I think that WPF is more than just a new framework or new classes. It is more than that because when you work with WPF, you have to change the way you think and design your apps.

• You have to change the way your work with controls because you can apply new Style and Template to them so that you can completely change the way they look
• You have to change the way you design your apps because of DataBinding and Commands
• You have to… forget almost every things you already know, and be ready to learn again !

If I can give an advice, I would suggest to read a good WPF book. A couple of weeks ago, I finished to read WPF unleashed, by Adam Nathan ¹, and I really think that having this kind of the book is the right way start working with WPF. A lot of cool website are also full of interesting resources, CodeProject is maybe the one that I like the most.

To conlude, I would like to give a quick example ².

Imagine you’d like to build an application to browse a catalog of products. For each product, you need to see the name of the product, its designer, a description and an image. You also would like to have navigation build around the use of 2 arrows to browse products:

How could you achieve this ? You might think about several ways to do it. The point is that you can do this by only using a ListBox and changing its style ! Isn’t amazing ? Go ahead and check the full video at http://sessions.visitmix.com/.