My current project is a Windows application implemented using Windows Presentation Foundation (WPF). I mostly do web and server side development using ASP.NET. This is the first time I have worked on a Windows application since the era of Visual Basic 6 about 10 years ago. Back then people thought of web development as strange and esoteric. Ironically the situation is now reversed and young web savvy developers view Windows development as a strange and esoteric world! In this post I will outline the similarities and differences I found between ASP.NET (Web Forms & MVC) and WPF.

Years of ASP.NET have trained us for XAML!

In ASP.NET Web Forms you build the user interface by adding a series of control elements such as <asp:button> and <asp:dropdown> on to a Web Form/html page. The Web Form development model was built to help people from a Windows development background to become productive in web development. The WPF development model works in much the same way. You add a series of control to a form. The forms and controls are represented in Extensible Application Markup Language (XAML) markup. Adding and editing the controls can be done with the Visual Studio designer or by hand. I have found it more productive to edit the markup directly.

Here is an example of a simple form:

<StackPanel>
   <Label style="flashy">Hello:</Label>
   <Button onclick="on_click">World</Button>
</StackPanel>

At runtime the application groups these controls into a logical control tree similar to the ASP.NET Web Forms control tree. There is also a ‘parallel’ visual control tree created which renders the form differently depending on the current styling or Windows settings. The visual control tree is analogous to the HTML that a Web Form actually renders.

Just like ASP.NET Web Forms WPF allows you to split your markup into separate user controls. This reduces complexity and enables reuse.  Styles can be defined in a separate XAML file to customize the look of a control across the application. Styles are similar to Themes in ASP.NET Web Forms or Cascading Style Sheets (CSS) in standard web development.

WPF forms and user control have a code behind file where you can place code to respond to user interactions and customise the interface. The best practice here is similar to ASP.NET Web Forms – the code behind should only be used for behaviour that is directly related to the user interface. Where possible separated presentation should be used (see below).

Data binding – it works!

ASP.NET data binding is something I have avoided. For simple read only scenarios it just about works. For complex or two way binding scenario it soon becomes more trouble than it is worth. Data binding in WPF is much more powerful. This power brings with it a complex syntax, but overall it is effective and delivers on its promise.  When coupled with a View Model (discussed below) it eliminates a lot of tedious code needed to populate controls.

Data binding example

<Window DataContext="Person">
     <TextBox Text="{Binding path=FirstName, UpdateSourceTrigger=PropertyChanged}"/>
</Window>

Commands – who needs events

WPF has a command infrastructure (based on the command pattern) that offers a powerful and flexible alternative to events. Instead of hooking up an event handler method to a control a command object can be hooked up to the control. A command object must implement the following interface:

interface ICommand
{
    void Execute(..,..);
    bool CanExecute();
}

When the user interacts with the control, by clicking a button for example, the command is executed. The control can also enable or disable itself based on the value returned from the CanExecute method.

Separated presentation – where did the controller go?

Separated presentation is the use of patterns such as Model View Controller (MVC) and Model View Presenter (MVP) to make our interface code easier to understand, change and unit testing. In uSwitch we use the MVP pattern in our ASP.NET Web Forms applications. A former colleague, Mike Wagg, introduced the concept of a View Model (Mike has some excellent post about MVC/MVP: Managing Complexity with MVP and a Presentation Model and  Presentation Patterns). The View Model represents what you see on the screen  and acts as a data transfer object (DTO) between the view and the presenter. ASP.NET MVC even has the idea of a View Model built into the framework.

In WPF development the dominant pattern is Model View View Model (MV-VM). The View Model in MV-VM is similar to the View Model in ASP.NET development but the View Model also handles the user interactions. This job is normally done by the controller in MVC. This architecture is enabled by the rich data binding support and command infrastructure in WPF. Having no “controller” seems quite strange at first, but it soon becomes natural. The controller is effectively gotten rid of/merged with the View Model. MV-VM shows the influence that a technology can have on how a pattern (MVC) is implemented. The article WPF Apps With The Model-View-ViewModel Design Pattern by Josh Smith is an excellent introduction.

MVP is still favoured by some developers. One advantage of MVP is that it makes it easier to decide which view to show based on the some criteria.

Persistence – prepare for a long session

For our applications we use NHibernate to handle persistence. Persistence is more complex in Windows development than in the web development. In the web environment an application usually has a request-response model. An NHibernate session is opened at the start of the request, the object model is changed and the session is then flushed/committed at the end of the request. This all happens in a few seconds.

In a Windows application however your session is usually tied to the lifetime of the screen the user is working on. This screen stays open for minutes not seconds. This means that an NHibernate session must be opened when a screen is created and stay open until the screen is closed. Ayende Rahien has an excellent article, Building a Desktop To-Do Application with NHibernate, on MSDN that covers this in more depth.

For web development we use a wrapper library around NHibernate. However for Windows application development we decided to use NHibernate directly in order to control and understand exactly what is going on. The lifetime of sessions was challenging to manage from an Inversion of Control (IoC) container perspective. Germán Schuager provides an excellent solution to this problem in his post Rich-client NHibernate session management.

Summary

Writing an application for a different environment was quite challenging, but also quite refreshing. The experience helped me to understand presentation and persistence patterns much better by seeing them from different perspectives. I hope this post helps you make the leap from the web to the desktop.