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.
How Optional Arguments in C# 4 Actually Work
In my last post, I discussed one of my favorite new features in C# – Optional and Named Arguments. Although they are very easy to use, and quite intuitive, I have seen few discussions which explain how they actually work. Understanding how they are implemented helps in understanding the repercussions of using these features in development.
Optional and Named Arguments in C# 4
After focusing on some of the .NET framework enhancements, I thought I’d turn my attention to two of my most anticipated new features coming with C# 4 – Optional and Named Arguments. These two features provide benefits I haven’t seen mentioned in most of the announcements…
Strings get even better with .NET 4
Handling text has always been the bane of my programming career. Starting off as a C developer forever tainted me when it comes to processing text; it’s difficult for me to not cringe every time I think of having to do text parsing. String manipulation in .NET was a pleasant surprise for me – when I started with C# I found I suddenly lost my urge to wince every time I had to deal with text input, and no longer was I itching to jump over to a loosely typed language just for handling string manipulation. The System.String class in .NET provided most of the ease of use I missed in C (and even C++).
However, even in .NET, there have been little annoyances when dealing with the String class. Version 4 of the .NET framework, again, adds some functionality to simplify day to day programming tasks. It’s really nice to see that the base class library team is giving some attention to the core, very common classes. Here is a summary of the changes to the String class, and why they help.
Long overdue Enum goodness in .NET 4
The more I investigate the changes in Version 4 of the .NET framework, the more I find little tweaks that just reduce the pain of day to day programming. For example, the System.Enum class is getting some extra methods that finally make day to day programming a bit simpler.
Lazy initialization in .NET 4 – Lazy<T>
A very common pattern in programming is the Lazy Initialization Pattern. Version 4 of the .NET Framework makes using this pattern very, very easy.
