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.
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.
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.
Now that I’ve demonstrated how WPF can be written in the same manner, using the same methods as prior windowing frameworks, it’s time to explain why this is a bad idea. To do this effectively, I’m going to discuss a few things that WPF introduces, and explain how they should change the way all of us approach building user interfaces. One thing I do want to mention – this series is not meant to be a full tutorial on WPF, rather an explanation of how to use features in WPF effectively.
The first new concept in WPF I’ll introduce is the new, more powerful, more flexible model for Data Binding.
Better User and Developer Experiences – From Windows Forms to WPF with MVVM: Part 3, Our Application in WPF
One common misconception I see when people start off with WPF is that they feel that it’s unapproachable, too complicated, and too unwieldy. There some fundamental shifts that every developer must deal with when the first switch to WPF, but they are actually fairly minor. You can program against the Windows Presentation Foundation API using the same basic techniques that you used in Windows Forms.