Programming Model
The WPF class library consists of approximately 1,600 public types and more than 3,500 classes. As such, it has a considerably larger application programming interface (API) surface than either ASP.NET or Windows Forms. As you would expect from a .NET class library, all these classes can trace their ancestry back to System.Object. In addition, most WPF classes are based on so-called base elements: the UIElement, FrameworkElement, ContentElement, and FrameworkContentElement classes. These classes are responsible for basic item presentation and layout capabilities and are contained within the System.Windows namespace.
In addition to these four base element classes, a few other important base classes drive a lot of the functionality found in WPF:
Visual—This class is the core rendering unit within WPF; UIElement inherits from Visual, as do the higher-level classes such as Button.
DispatcherObject—This class supports the WPF threading model.
Control—This is the base class for controls in WPF.
Application—The Application class encapsulates all WPF applications; it provides application lifetime services, including the basic concepts of Run (to start an application) and Exit (to quit an application).
As you would expect, the WPF class library provides all the major controls that you would typically find in a Windows application, such as buttons, labels, list boxes, and text boxes.
The following snippet shows a WPF Button control being instantiated, and the text Push Me is assigned to the button. Note that the control constructs are familiar, but the actual object model is slightly different; the Button object in WPF does not have a .Text property as we would expect from an ASP.NET or WinForms button. Instead, it exposes a .Content property:
System.Windows.Controls.Button btn = new Button();
btn.Content = "Push Me";
Besides procedural code like that shown here, WPF enables us to create and manipulate objects in a declarative fashion using a markup syntax called XAML.
Extensible Application Markup Language
XAML is an XML dialect that can be used to describe the structure of a WPF application’s presentation layer (for example, control instantiation, appearance, and layout).
XAML is the principal way in which the various WPF tools define objects and set properties in a declarative fashion. As such, it is tempting to compare XAML to HTML. It certainly fills a similar role in that both XAML and HTML are declarative ways to describe objects. But XAML is actually tightly coupled to the .NET Framework. In fact, XAML is really describing which .NET objects to create, plus setting their properties and attaching event handlers. WPF tools, such as the WPF Designer in Visual Studio, happen to leverage XAML, but strictly speaking, XAML is not a part of WPF. You can write an entire XAML application, for instance, using only the managed code language of your choice. Because XAML, as a programming model, brings several important advancements to the scene, it is heavily leveraged by all the Microsoft and non-Microsoft tools in the WPF world and beyond. For instance, Windows Workflow Foundation uses it to describe workflows. It is also one of the ways that you can create Windows Store applications in Windows 8/10 (and even Windows Phone).
Just as we did previously, let’s create a Button object and assign some text to the button. But this time, let’s define it with XAML.
<Button Content="Push Me"/>
Alternatively, we could write this code like this:
<Button>Push Me</Button>
Basically, when you define an element in XAML, the WPF engine will create an instance of the given type (Button in this example) for you. When you give a value to an attribute, it will be translated as setting this value to the property (Content here) with the same name as the attribute to the newly created object.
Note
XAML functionality is a subset of what is possible in .NET code. Or, to put it another way, anything you can define in XAML you can do in code, but not everything done in code can be defined in XAML.
In a typical WPF application, XAML coexists with managed code through the same partial class paradigm introduced with ASP.NET. In other words, we may have a MainForm.xaml file with the look and feel of a window and a MainForm.xaml.vb (or .cs) file that contains code that reacts to a user’s input on that form. We see more of this in action a little later in this chapter when we take a close look at the WPF Designer.
If XAML isn’t necessary to create a WPF application, why is it desired? Given the fact that you can accomplish the necessary tasks to create UI objects in XAML or in managed code, why is XAML even in the picture? There are a few areas where the declarative syntax becomes tremendously important.
Syntax Parsing Simplicity
As is true with all XML-based languages, XAML is relatively easy for applications to parse and understand. Several developers have used this to their advantage and delivered lightweight tools for WPF development, such as XAMLPad. This has also enabled tool vendors, including Microsoft, to rapidly release products into the market that understand XAML. Adobe Illustrator, for example, has a XAML plug-in that enables you to emit XAML, and of course Microsoft has not one but two design tools that read and write XAML: Expression Design and Expression Blend.
The boundary between XAML and code also turns out to be a nice dividing line between appearance and behavior. In this scenario, XAML is used to define the UI objects and the general look and feel of the application, whereas procedural code is used to implement the business logic and to react to a user’s input. This leads us directly to the other important advantage of XAML: collaboration.
Collaboration
If we separate appearance and behavior, we can also reap the benefits of improved collaboration among project team members (specifically, collaboration between designers and developers). Before WPF, designers would rely on “flat” bitmaps created with drawing programs or would even rely on applications such as PowerPoint to mock up the user experience for an application. When that design is eventually handed off to the developer for implementation, there is an inherent disconnect: programming tools don’t understand 2D bitmaps or PowerPoint storyboards. They understand code and objects. And in the reverse direction, we have the same problem: tools made for designers don’t understand managed code. A developer can’t implement a form in Visual Basic, for example, and hand it back to a designer for review and tweaking.
So developers are forced to re-create, as best they can, the vision delivered from the design team. This is a decidedly second-rate way to design and build applications. But with XAML, this situation changes dramatically. Because designers can now use highly visual tools that generate their design in XAML behind the scene (such as Microsoft Expression Blend), the developer can simply open that XAML file in Visual Studio and provide the coding “goop” necessary to flesh out the desired features in the code behind file. In the process, we have completely preserved the fidelity of the designers’ original vision because the developer’s tools are talking the same language. We also have full collaboration in the other direction: changes that a developer makes to the designer’s XAML can be instantly reviewed and tweaked within the designer’s tools. This simple concept—the sharing of a codebase and language between design and development roles and tools—proves to be a powerful argument for leveraging XAML in your applications.
Now that we have covered the basics of WPF, let’s see how we can start writing WPF applications using Visual Studio.