User interface design for a professional application is not easy. It can be a dense mix of data, interaction design, visual design, connectivity, multi-threading, security, internationalization, validation, unit testing, and a dash of “living water” on top of that. Given that the UI represents the underlying system and must satisfy unpredictable user stylistic requirements, it can be the most fickle part of many applications.
There are popular design patterns that help tame this monster, but the task of properly separating the many issues and resolving them can be difficult. The more complex the patterns, the more likely it is that simplifications will then be used that devalue all previous attempts to make things the best they can be.
Design patterns are not always to blame. Sometimes we use complex design patterns for which we need to write a lot of code because the UI platform being used is not compatible with the simpler pattern. What we need is a platform that allows us to create user interfaces using simple, time-tested, and programmer-approved design patterns. Fortunately, Windows Presentation Foundation (WPF) provides just that.
As WPF becomes more and more recognized in the world of programmers and users, the WPF community is developing its own “ecosystem” of patterns and practical guidelines. In this article, I’ll explore some of these practical guidelines for designing and implementing client applications in WPF. Using the core features of WPF along with the Model-View-View-View-Model (MVVM) design pattern, I’ll walk through a sample program that shows that it’s not hard at all to do a WPF application “right”.
By studying this article, you’ll learn how to fit together data patterns, commands, data binding, resource system, and the MVVM pattern to create a simple, testable, and robust infrastructure in which any WPF application can thrive. The sample program that accompanies this article can serve as a template for a real WPF application that uses MVVM as the underlying architecture. The unit tests in the sample solution show how easy it is to test the application’s user interface features when those features are represented by a set of ViewModel classes. Before we dive into the details, let’s first consider why we should use a pattern like MVVM.
Order vs. Chaos
Using design patterns in a simple program like “Hello, world!” is unnecessary and even harmful. Any skilled developer will immediately understand a couple lines of code. But as the number of program features increases, so does the number of lines of code and moving parts. At some point, the complexities of the system and its inherent problems force developers to organize code so that it is easier to understand, discuss, extend, and troubleshoot. We reduce the cognitive chaos of a complex system by naming certain elements of the source code with known names. We define the name assigned to a piece of code by its functional role in the system.
Developers often intentionally structure code according to a design pattern, not allowing patterns to emerge naturally. Both approaches are good, but in this article I’ll discuss the benefits of directly using MVVM as the architecture for a WPF application. Some class names include known terms from the MVVM pattern, such as the ending “ViewModel” if the class is a view abstraction. This approach helps avoid the cognitive chaos mentioned above. Instead, you can happily stay in a state of controlled chaos, the natural state of affairs in most professional software development projects!