Last year, I wrote about making Christmas Trees in WPF using FSharp.ViewModule. At the time, I was excited being able to demonstrate how FSharp.ViewModule could make typical MVVM much more functional feeling. This year, for my F# Advent Calendar contribution, I want to demonstrate how Gjallarhorn.Binding can serve as a replacement, and help create a WPF application with a design that is clean, functional, and most importantly, simple.
This post will modernize the Christmas Tree application from last year, improving it, and highlighting the differences between a classic MVVM approach to WPF and a more functional approach. While reading through the post from last year would add context, it’s completely optional.
As my contribution to the F# Advent Calendar this year, I thought I’d write a bit about one approach I often use to create WPF user interfaces in a functional style – mixing MailboxProcessor with FSharp.ViewModule.
This post will illustrate using a pair of MailboxProcessor instances mixed with FSharp.ViewModule to construct a simple application. In the spirit of F# Advent, our application will be a small drawing application that allows us to place and decorate Christmas trees.
Typically, I strongly recommend keeping the user interface within an application’s main thread, and using multiple threads to move the actual “work” into background threads. However, there are rare times when creating a separate, dedicated thread for a Window can be beneficial. This is even acknowledged in the MSDN samples, such as the Multiple Windows, Multiple Threads* sample. However, doing this correctly is difficult. Even the referenced MSDN sample has major flaws, and will fail horribly in certain scenarios. To ease this, I wrote a small class that alleviates some of the difficulties involved.
While similar to the WindowCloseBehavior code I posted on the Expression Code Gallery, Nishant Sivakumar’s version works in WPF without taking a dependency on the Expression Blend SDK.
I highly recommend reading this article: Handling a Window’s Closed and Closing Events in the View-Model. It is a very nice alternative approach to this common problem in MVVM.
The Managed Extensibility Framework is an amazingly useful addition to the .NET Framework. I was very excited to see System.ComponentModel.Composition added to the core framework. Personally, I feel that MEF is one tool I’ve always been missing in my .NET development.
Unfortunately, one perfect scenario for MEF tends to fall short of it’s full potential is in Windows Presentation Foundation development. In particular, there are many times when the XAML parser constructs objects in WPF development, which makes composition of those parts difficult. The current release of MEF (Preview Release 9) addresses this for Silverlight developers via System.ComponentModel.Composition.CompositionInitializer. However, there is no equivalent class for WPF developers.
This series introduces the Model-View-ViewModel Pattern from the point of view of a Windows Forms developer. The goal is not to introduce WPF, but to demonstrate some of the new features within Windows Presentation Foundation, and show how they should force every WPF developer to re-think how they design their applications.
The Model-View-ViewModel pattern is introduced after a discussion of three of the main features in WPF which enable it’s usage. In order to illustrate this, three versions a single application were written:
- A Windows Forms application
- A WPF Version of the application, using the same style
- A WPF Version of the application, built using MVVM
This allows a detailed understanding of the reasons behind MVVM, as well as the technology that enables the pattern.
Windows Presentation Foundation provides us with new opportunities to build applications that are very flexible to design, easy to maintain, and clear to understand. By taking advantage of Data Binding, Commands, and Templating, we can rethink the way we build our applications, and design them using the Model-View-ViewModel Pattern.
Now that I’ve walked through how we do this, I will revisit our original RSS Feed Reader application, and show samples of how this changes the design and code in this simple application.
I mentioned in the introduction that a new architectural pattern has emerged for Windows Presentation Foundation: Model-View-ViewModel. As I mentioned, MVVM can make developing applications in WPF efficient, quick, and highly maintainable. Now that I’ve covered some of the basic technological advances in WPF, mainly Data Binding, Commands, and Templating, it’s time to bring everything together, and demonstrate how this improves our jobs as developers.
In order to rethink how we architect and write client applications, there is one last important concept Windows Presentation Foundation introduces, beyond the excellent Data Binding and Commanding support I’ve already discussed. WPF adds an entire suite of features specifically related to Styling and Templating. This is often discussed in relation to improving the overall look, feel, and usability of applications written using WPF – the key to the new user experience (UX) WPF allows. However, the templating engine introduced with WPF has other side effects, which change the way we should design our software, not just change the way we stylize our software.
In the last article, I explained how Windows Presentation Foundation improves upon data handling via it’s excellent support for data binding. However, data is only part of the equation. In order to be a more effective framework, WPF also provides us a way to more effectively handle our application specific logic.
It does this by providing a unified model for separating the originator of an action from the effect produced by the action, via the Commanding infrastructure.