The Windows Presentation Foundation Platform

WPF brings a lot of new concepts and new coding territory with it (and can represent a fairly significant learning curve for developers). But let’s take a brief look at the overall architecture of the WPF platform and then dissect the programming model.

Physically, WPF is implemented with a series of three assemblies:

WindowsBase.dll

PresentationFramework.dll

PresentationCore.dll

Every presentation layer framework has to eventually paint pixels onto a screen, and WPF is no different. Implemented within its binaries is a composition and rendering engine that talks to your hardware through DirectX. In addition to the rendering layers, there is obviously a rich programming model that is implemented with deep support for things such as layout, containership (the capability for one element to contain another), and events/message dispatches. In short, it does all the heavy lifting to ensure that some complicated user interface scenarios can be rendered on the screen with enough performance to appeal to a wide range of solution scenarios.

Figure 21.1 shows the logical architecture of the various WPF components. The actual rendering “engine” is contained within the Media Integration Layer component; PresentationCore handles interop with the Media Integration Layer, and PresentationFramework contains all the other magic necessary to make WPF successful as an end-to-end platform such as layout, data binding, and event notifications.

FIGURE 21.1 WPF logical architecture.

All these WPF components work in concert to deliver an impressive laundry list of improvements to the state of the art with regard to presentation layer design, construction, and runtime support with .NET. Here is a small sample:

Media—WPF supports 2D and 3D graphics, as well as WMV, MPEG, and AVI video.

Data binding—WPF was built from the start to fully support the entire spectrum of data-binding scenarios, up to and including LINQ and the Entity Framework.

Windows Forms interoperability—WPF applications can host WinForms components and vice versa. This is comforting because it means developers won’t need to abandon the hard-won knowledge that comes with programming WinForms for many years.

Document support—WPF has several native constructs for building document-centric applications. For instance, there is a DocumentReader class for displaying fixed-format documents and a FlowDocumentReader class for displaying documents with a dynamic layout. Think of a newspaper article, for instance, that automatically repaginates while remaining true to the column structure.

Animation—Developers can create storyboard-based animations and specify animation triggers and timers.

Control “look and feel”—Controls in WPF have their appearance controlled by a template, which developers can replace or change to fully customize nearly every aspect of a control’s “chrome.”

Text—There is rich typography support in WPF. Developers can manipulate a slew of font attributes (kerning; effects such as glow, drop-shadows, and motion blur; auto line spacing; and so on), and WPF developers can choose to have text rendered using ClearType technology or via two additional rendering modes introduced in WPF 4: aliased and grayscale.

During the initial beta cycles, Microsoft produced a series of prototype applications to showcase the new technologies in .NET 3.0, including WPF. Figure 21.2 shows a screenshot from one of those original prototypes (in this case, a healthcare application). Although a static shot like this doesn’t do the application much justice, you can get a good sense for the possibilities. The UI for this application would have been extremely difficult to implement using Windows Forms technology.

FIGURE 21.2 An early WPF-based healthcare application prototype.

For the most part, developers are free to not worry so much about the low-level architectural details of WPF; the programming model (and the tools which help us leverage that model) is where most developers will focus their energies.