WPF architecture contains all the class hierarchy and the
methods of interacting with each other.
System.Object
WPF applications are exposed through managed code. So the
CLR has many productive and robust development features like memory management,
error handling, common type system etc. The major components are Presentation
framework, Presentation Core, Common Language Runtime, Milcore, DirectX,
User32, Kernel. Out of these only PresentationFramework,
PresentationCore, and Milcore are the major code portions of the WPF
applications. Milcore is written in unmanaged code in
order to enable tight integration with DirectX. All display in WPF is done
through the DirectX engine, allowing for efficient hardware and software
rendering. WPF also required fine control over memory and execution. The
composition engine in milcore is extremely performance sensitive, and required
giving up many advantages of the CLR to gain performance.
System.Threading.DispatcherObject
Most of the WPF objects are derived from DispatcherObject,
which provides basic methods dealing with concurrency and threading. WPF is
based on messaging system implemented by the dispatcher.
System.Windows.DependencyObject
One of the primary architectural
philosophies used in building WPF was a preference for properties over methods
or events. Properties are declarative and allow you to more easily specify
intent instead of action. This also supported a model driven, or data driven,
system for displaying user interface content. This philosophy had the intended
effect of creating more properties that you could bind to, in order to better
control the behavior of an application.
In order to have more of the system driven by properties, a
richer property system is needed than what the CLR provides. A simple example
of this richness is change notifications. In order to enable two-way binding,
you need both sides of the bind to support change notification. In order to
have behavior tied to property values, you need to be notified when the
property value changes. The Microsoft .NET Framework has an interface, INotifyPropertyChange,
which allows an object to publish change notifications, however it is optional.
WPF provides a richer property system, derived from the
DependencyObject type. The property system is truly a "dependency"
property system in that it tracks dependencies between property expressions and
automatically revalidates property values when dependencies change. For
example, if you have a property that inherits (like FontSize), the system is
automatically updated if the property changes on a parent of an element that
inherits the value.
The foundation of the WPF property system is the concept of
a property expression. In this first release of WPF, the property expression
system is closed, and the expressions are all provided as part of the
framework. Expressions are why the property system doesn’t have data binding,
styling, or inheritance hard coded, but rather provided by later layers within
the framework.
The property system also provides for sparse storage of
property values. Because objects can have dozens (if not hundreds) of
properties, and most of the values are in their default state (inherited, set
by styles, etc.), not every instance of an object needs to have the full weight
of every property defined on it.
The final new feature of the property system is the notion
of attached properties. WPF elements are built on the principle of composition
and component reuse. It is often the case that some containing element (like a
Grid layout element) needs additional data on child elements to control its
behavior (like the Row/Column information). Instead of associating all of these
properties with every element, any object is allowed to provide property
definitions for any other object. This is similar to the "expando"
features of Javascript.
System.Windows.Media.Visual
The
Visual class provides for building a tree of visual objects, each optionally
containing drawing instructions and metadata about how to render those
instructions (clipping, transformation, etc.). Visual is designed to be
extremely lightweight and flexible, so most of the features have no public API
exposure and rely heavily on protected callback functions.
Visual class is really the entry point to the WPF
composition system. Visual class is the point of connection between these two
subsystems, the managed API and the unmanaged milcore.
WPF displays data by traversing the unmanaged data
structures managed by the milcore. These structures, called composition nodes,
represent a hierarchical display tree with rendering instructions at each node.
This tree, illustrated on the right hand side of the figure below, is only accessible
through a messaging protocol.
When programming WPF, you create Visual elements, and
derived types, which internally communicate to the composition tree through
this messaging protocol. Each
Visual in WPF may create one, none, or several
composition nodes.
System.Windows.UIElement
UIElement defines the core subsystems including Layout, Input, and Events. Layout is a core concept in WPF. In many systems there is either
a fixed set of layout models (HTML supports three models for layout; flow,
absolute, and tables) or no model for layout (User32 really only supports
absolute positioning). WPF started with the assumption that developers and
designers wanted a flexible, extensible layout model, which could be driven by
property values rather than imperative logic. At the UIElement level, the basic
contract for layout is introduced – a two phase model with Measure
and Arrange
passes.
System.Windows.FrameworkElement
FrameworkElement can be looked at in two different ways. It
introduces a set of policies and customizations on the subsystems introduced in
lower layers of WPF. It also introduces a set of new subsystems.
The primary policy introduced by FrameworkElement is around
application layout. FrameworkElement builds on the basic layout contract
introduced by UIElement and adds the notion of a layout "slot" that
makes it easier for layout authors to have a consistent set of property driven
layout semantics.
System.Windows.Controls.Control
Control class provides a set of stock properties, Foreground, Background,
Padding to name a few, which template authors can then use to customize the
display of a control. The implementation of a control provides a data model and
interaction model. The interaction model defines a set of commands (like Close
for a window) and bindings to input gestures (like clicking the red X in the
upper corner of the window). The data model provides a set of properties to
either customize the interaction model or customize the display (determined by
the template).
