Better User and Developer Experiences – From Windows Forms to WPF with MVVM: Part 4, Data Binding
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.
Better User and Developer Experiences – From Windows Forms to WPF with MVVM: Part 2, Our Application in Windows Forms
In order to fully understand how and why to migrate from Windows Forms to WPF, and from WPF to WPF using MVVM, we need to understand Windows Forms.
When Microsoft first developed and released .NET, they provided a very clean, simple API for creating Windows applications based upon existing technologies: Windows Forms. The Windows Forms programming model is an event based programming model. This matches very well with prior Microsoft technologies, such as ATL and MFC, since the core of Windows Forms wraps around controls defined in the Windows API.
Better User and Developer Experiences – From Windows Forms to WPF with MVVM: Part 1, The Model
Before we can make a user interface for a program, we need to know what the program is going to do. Hopefully, we have some logic we’re going to be exposing to our users. Underneath all of the beautiful user interfaces we build there is something that we’re trying to accomplish, some data we’re editing or information we’re conveying. Before we can discuss how to make an effective user experience, we need to define the core information with which we are working.
Better User and Developer Experiences – From Windows Forms to WPF with MVVM: Introduction
I frequently talk to people trying to decide, for a new project, between Windows Forms and Windows Presentation Foundation. After spending time with WPF, I feel there is no reason to choose Windows Forms for new development. WPF, when used correctly, is far superior, both in terms of user experience, but also developer productivity.
I feel that the confusion around choosing WPF really stems from a lack of understanding about WPF. Even people on my own team have been overwhelmed trying to understand how the different pieces of WPF fit together, and how to apply the new concepts introduced with WPF effectively. In order to address this, I’m going to break this down into a few simple pieces, and show the migration in terms of thought required to transition from being a good Windows Forms developer to an effective WPF developer.
Synchronizing .NET 4 Tasks with the UI Thread
While attending the Patterns of Parallel Programming Workshop at PDC, I picked up a very interesting tidbit from Stephen Toub’s talk: the new Task pattern in .NET 4 has built-in support for synchronization with the UI thread. This makes writing parallel applications that interact with the user interface easier than ever before.
Thread specific data becomes easier in .NET 4.0 via ThreadLocal<T>
Occasionally, when dealing with multithreaded code, there are uses for data that is kept in a manner that is unique to the currently running thread. This is accomplished via using Thread-local storage. Typically, in .NET 3.5, this was handled via the [ThreadStatic] attribute, however, this puts certain restrictions on usage. The main problem with ThreadStatic is that it is exactly that – static data stored per thread. This can be problematic, especially if you’re using ThreadPool threads, as the data is never released cleanly.
Currently, if you want to use data kept at a local scope with a copy per thread, the solution is to use a LocalDataStoreSlot to manage your threaded data. This works, but is not very developer-friendly. It is not type-safe; all data is stored as a System.Object. It is clunky at best to use, especially if you want to free, as you have to use and track strings with named data slots in order to release the memory. Version 4 of the .NET Framework fixes all of these issues by introducing ThreadLocal<T>.
Unusual uses of ExpandoObject in C# 4
One of the new features in C# 4 is the use of the dynamic keyword, allowing types to be defined with no regard to static type checking. Although many of the use cases for this revolve around interoperability, especially with dynamic languages and COM, there are types in the framework designed to make this available for use internally in C# programs as well. The simplest dynamic implementation in .NET 4 is System.Dynamic.ExpandoObject.
