his article presents an advanced technique that lets you bind multiple editable line items to a collection using Windows Presentation Foundation and the Presentation Model pattern. It assumes you are familiar with basic WPF data binding techniques as well as design patterns that object-oriented UI libraries typically use. After an introduction to the sample application used throughout this article, you'll see how applying the Presentation Model pattern insulates this application's UI and business logic layers from one another. Finally, you'll see the WPF-specific details involved in binding a Presentation Model to XAML controls to create a dynamic UI with multiple editable line items.
A Dynamic User Interface
To illustrate the meaning of "a dynamic UI with multiple editable line items," it's useful to begin with a contrasting example—a static interface. In this use case, a web-based account registration form asks users for personal information, and maps their answers to a corresponding business object or database table, which represents a user profile. After users fill out and submit the form, the site stores their personal information, and sends a confirmation e-mail, which completes the use case. Assuming the UI and validation code is correct, consider that the developer who wrote the form knew the exact information needed in advance, and could therefore constrain users from entering invalid data; in other words, the interface is static
—validation paramters for the requested information are known in advance, and the UI doesn't change from one instance of the application to the next.
In contrast, consider a transaction register that lets you track day-to-day expenses. In this form, users might enter one expense or twenty. The developer in charge of writing such an application could play it safe by displaying some large preset number of empty line items (more than anyone would want to enter for a single day), but that would be a less than elegant approach. A better alternative would be a UI that generates new line items on demand. This is a dynamic UI because the developer cannot know the exact volume of information (the number of items) in advance. The dynamic UI approach is more intuitive, minimizes on-screen clutter, and lets users focus on the line items at hand by adjusting the number of items to suit the immediate need.
A Sample Application: Expenses.NET
The sample application for this article, "Expenses.NET," is exactly such a dynamic-UI transaction register (see Figure 1). It lets you itemize expenses day by day within a weekly period. Upon launch, the center of the UI displays a ListView with a single ListViewItem. The ListViewItem contains a ComboBox to select the weekday and date of each expense, a TextBox to enter a description of the expense, another TextBox to enter an amount, and two buttons that allow users to add additional line items or delete existing items. A business object called ExpenseLineItem backs each ListViewItem. The ExpenseLineItem class exposes properties corresponding to each of the controls listed above, and implements the INotifyPropertyChanged interface to work with the WPF binding framework. Another business object called ExpenseSheet backs the ListView itself. ExpenseSheet contains an ObservableCollection of ExpenseLineItems.
The Presentation Model Pattern
|Figure 1. Expenses.NET in Action: The screen capture shows the sample application with a single filled-out expense.||
|Figure 2. The Presentation Model: This model uses data from business objects to drive the state of the entire UI.||
The Presentation Model pattern (see Figure 2
) lies at the heart of Expenses.NET. You won't find a chapter on this pattern in the classic Gang of Four Design Patterns book (Design Patterns: Elements of Reusable Object-Oriented Software
), but Martin Fowler has devoted a page to it on the Enterprise Application Architecture
section of his web site. To quote Fowler, the pattern is a way to "represent the state and behavior of the presentation independently of the GUI controls used in the interface." You might be wondering how that differs from MVC or similar patterns that UI control libraries typically use—and, it doesn't really; it is an application-level abstraction above the controls that uses data from business objects to drive the state of the entire
user interface. The properties of the business objects correspond to properties on the controls. In this case, WPF data binding is the glue that keeps them synchronized. This is a powerful abstraction, because it isn't platform-specific; you can reuse it against other UIs targeted toward technologies such as ASP.NET web applications or mobile devices.