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.
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.
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.
Unlike standard .NET properties, implementing a DependencyProperty requires a bit more code, and has the potential to cause nasty errors to creep up at runtime, without any compile time warnings. Here’s one easy, common mistake, as well as an explanation of why it occurs…
It is very difficult to handle situations in a master-detail view, where the master side displays a value derived from aggregating the detail collection. The Model-View-ViewModel pattern makes this even more challenging, since most means of handling this require changing your model, or using extensive code behind.
One common issue people face in the Model-View-ViewModel pattern is how to cleanly deal with the lifetime of the View from within the ViewModel. Keeping all of the logic in the ViewModel for preventing the View from closing can be a daunting task, especially at first.