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.
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.