WPF アーキテクチャWPF Architecture

このトピックでは、Windows プレゼンテーション ファウンデーション (WPF) クラス階層のガイドツアーを提供します。This topic provides a guided tour of the Windows Presentation Foundation (WPF) class hierarchy. WPF の主要なサブシステムの大部分をカバーし、その相互作用について説明します。It covers most of the major subsystems of WPF, and describes how they interact. また、WPF のアーキテクトが行った選択の一部についても詳しく説明します。It also details some of the choices made by the architects of WPF.


プライマリ WPF プログラミング モデルは、マネージ コードを通じて公開されます。The primary WPF programming model is exposed through managed code. WPF の設計段階の初期段階では、システムのマネージ コンポーネントとアンマネージ コンポーネントの間に線を引く場所について、さまざまな議論がありました。Early in the design phase of WPF there were a number of debates about where the line should be drawn between the managed components of the system and the unmanaged ones. CLR には、開発の生産性と堅牢性 (メモリ管理、エラー処理、共通型システムなど) を実現する機能が多数用意されていますが、コストがかかります。The CLR provides a number of features that make development more productive and robust (including memory management, error handling, common type system, etc.) but they come at a cost.

WPF の主要なコンポーネントを次の図に示します。The major components of WPF are illustrated in the figure below. 図の赤いセクション (プレゼンテーション フレームワーク、プレゼンテーションコア、およびミルコア) は、WPF の主要なコード部分です。The red sections of the diagram (PresentationFramework, PresentationCore, and milcore) are the major code portions of WPF. このうち、1つだけがアンマネージコンポーネントであるミルコアです。Of these, only one is an unmanaged component – milcore. Milcore は、DirectX との緊密な統合を可能にするために、アンマネージ コードで記述されています。Milcore is written in unmanaged code in order to enable tight integration with DirectX. WPF での表示はすべて DirectX エンジンを通じて行われるため、効率的なハードウェアとソフトウェアのレンダリングが可能になります。All display in WPF is done through the DirectX engine, allowing for efficient hardware and software rendering. WPF では、メモリと実行を細かく制御する必要もありました。WPF also required fine control over memory and execution. milcore の合成エンジンは非常にパフォーマンスに敏感であり、パフォーマンスを得るためには CLR の多くの利点を放棄する必要があります。The composition engine in milcore is extremely performance sensitive, and required giving up many advantages of the CLR to gain performance.

.NET Framework 内の WPF の位置。The position of WPF within the .NET Framework.

WPF のマネージ部分とアンマネージ部分の間の通信については、このトピックで後ほど説明します。Communication between the managed and unmanaged portions of WPF is discussed later in this topic. マネージ プログラミング モデルの残りの部分を以下に説明します。The remainder of the managed programming model is described below.


WPF のオブジェクトの多DispatcherObjectくは、 から派生し、同時実行とスレッド処理を処理するための基本的な構成要素を提供します。Most objects in WPF derive from DispatcherObject, which provides the basic constructs for dealing with concurrency and threading. WPF は、ディスパッチャーによって実装されるメッセージング システムに基づいています。WPF is based on a messaging system implemented by the dispatcher. これは、使い慣れた Win32 メッセージ ポンプとよく似ています。実際、WPF ディスパッチャーは、スレッド間呼び出しを実行するために User32 メッセージを使用します。This works much like the familiar Win32 message pump; in fact, the WPF dispatcher uses User32 messages for performing cross thread calls.

WPF での同時実行について説明する際に理解する必要のある 2 つの主要な概念 、つまりディスパッチャーとスレッドアフィニティがあります。There are really two core concepts to understand when discussing concurrency in WPF – the dispatcher and thread affinity.

WPF の設計段階では、単一の実行スレッドに移行することが目標でしたが、非スレッドの "アフィニティ化" モデルに移行することが目標でした。During the design phase of WPF, the goal was to move to a single thread of execution, but a non-thread "affinitized" model. スレッドの類似性は、コンポーネントが実行スレッドの ID を使用して何らかの状態を格納するときに発生します。Thread affinity happens when a component uses the identity of the executing thread to store some type of state. 最も一般的な形式は、スレッド ローカル ストア (TLS) を使用して状態を格納することです。The most common form of this is to use the thread local store (TLS) to store state. スレッドアフィニティでは、実行の各論理スレッドがオペレーティング システム内の 1 つの物理スレッドだけが所有している必要があり、メモリを集中的に消費する可能性があります。Thread affinity requires that each logical thread of execution be owned by only one physical thread in the operating system, which can become memory intensive. 最終的に、WPF のスレッド モデルは、スレッド アフィニティを使用した単一スレッド実行の既存の User32 スレッド モデルとの同期を維持しました。In the end, WPF’s threading model was kept in sync with the existing User32 threading model of single threaded execution with thread affinity. この主な理由は、OLE 2.0、クリップボード、Internet Explorer などのシステムで、シングル スレッド アフィニティ (STA) の実行が必要なため、相互運用性が実現しました。The primary reason for this was interoperability – systems like OLE 2.0, the clipboard, and Internet Explorer all require single thread affinity (STA) execution.

STA スレッドを持つオブジェクトが存在する場合、スレッド間で通信し、正しいスレッドであることを検証する方法が必要です。Given that you have objects with STA threading, you need a way to communicate between threads, and validate that you are on the correct thread. ここにディスパッチャーの役割があります。Herein lies the role of the dispatcher. ディスパッチャーは、複数の優先順位付きキューを持つ基本的なメッセージディスパッチシステムです。The dispatcher is a basic message dispatching system, with multiple prioritized queues. メッセージの例としては、生の入力通知 (マウス移動)、フレームワーク関数 (レイアウト)、またはユーザー コマンド (このメソッドを実行) などがあります。Examples of messages include raw input notifications (mouse moved), framework functions (layout), or user commands (execute this method). からDispatcherObject派生すると、STA 動作を持つ CLR オブジェクトを作成し、作成時にディスパッチャーへのポインターを与えます。By deriving from DispatcherObject, you create a CLR object that has STA behavior, and will be given a pointer to a dispatcher at creation time.


WPF の構築に使用される主なアーキテクチャの哲学の 1 つは、メソッドやイベントよりもプロパティの優先順位でした。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.

プロパティによって駆動されるシステムの多くを持つためには、CLR が提供するものよりも豊富なプロパティ システムが必要でした。In order to have more of the system driven by properties, a richer property system than what the CLR provides was needed. このリッチさの簡単な例は、変更通知です。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. インターフェイスINotifyPropertyChangeを使用すると、オブジェクトが変更通知を発行できますが、オプションです。The Microsoft .NET Framework has an interface, INotifyPropertyChange, which allows an object to publish change notifications, however it is optional.

WPF には、型から派生した、よりDependencyObject豊富なプロパティ システムが用意されています。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. たとえば、値を継承する要素の親のプロパティが変更FontSizeされると、(など)プロパティを継承する場合、システムは自動的に更新されます。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.

WPF プロパティ システムの基礎は、プロパティ式の概念です。The foundation of the WPF property system is the concept of a property expression. WPF のこの最初のリリースでは、プロパティ式システムが閉じられ、式はすべてフレームワークの一部として提供されます。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 要素は、構成とコンポーネントの再利用の原則に基づいて構築されます。WPF elements are built on the principle of composition and component reuse. 多くの場合、(レイアウト要素のような) 要素をGrid含む一部の要素は、子要素の動作を制御するために追加のデータを必要とします (行/列情報など)。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. これは、JavaScript の "展開" 機能に似ています。This is similar to the "expando" features of JavaScript.


システムが定義されている場合、次のステップは画面に描画されるピクセルを取得することです。With a system defined, the next step is getting pixels drawn to the screen. この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非常に軽量で柔軟性を持つように設計されているので、ほとんどの機能はパブリック API を公開することはなく、保護されたコールバック関数に大きく依存しています。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は、WPF 合成システムへのエントリ ポイントです。Visual is really the entry point to the WPF composition system. Visualは、マネージ API とアンマネージ ミルコアという 2 つのサブシステム間の接続ポイントです。Visual is the point of connection between these two subsystems, the managed API and the unmanaged milcore.

WPF は、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.

WPF をプログラミングする場合、Visualこのメッセージング プロトコルを通じて構成ツリーに内部的に通信する要素と派生型を作成します。When programming WPF, you create Visual elements, and derived types, which internally communicate to the composition tree through this messaging protocol. WPFVisualの各ノードは、1 つ、どれも、または複数のコンポジション ノードを作成できます。Each Visual in WPF may create one, none, or several composition nodes.

Windows Presentation Foundation ビジュアル ツリー。The Windows Presentation Foundation Visual Tree.

ここで注目する非常に重要なアーキテクチャの詳細があります - ビジュアルのツリー全体と描画命令がキャッシュされています。There is a very important architectural detail to notice here – the entire tree of visuals and drawing instructions is cached. グラフィックス用語では、WPF は保持されたレンダリング システムを使用します。In graphics terms, WPF uses a retained rendering system. これにより、ユーザー コードへのコールバックで合成システムがブロックされることなく、システムが高いリフレッシュ レートで再描画できます。This enables the system to repaint at high refresh rates without the composition system blocking on callbacks to user code. これにより、応答しないアプリケーションが表示されないようにできます。This helps prevent the appearance of an unresponsive application.

図ではあまり分からないもう 1 つの重要な詳細は、システムが実際にどのように構成を実行するかを示しています。Another important detail that isn’t really noticeable in the diagram is how the system actually performs composition.

User32 および GDI では、システムは即時モードクリッピング システムで動作します。In User32 and GDI, the system works on an immediate mode clipping system. コンポーネントをレンダリングする必要がある場合、システムは、コンポーネントがピクセルに触れることができない範囲外のクリッピング境界を確立し、そのボックスにピクセルをペイントするようにコンポーネントに求められます。When a component needs to be rendered, the system establishes a clipping bounds outside of which the component isn’t allowed to touch the pixels, and then the component is asked to paint pixels in that box. このシステムは、何かが変更されたときに影響を受けるコンポーネントに触れるだけで、2つのコンポーネントが単一ピクセルの色に寄与しないため、メモリに制約のあるシステムでは非常にうまく機能します。This system works very well in memory constrained systems because when something changes you only have to touch the affected component – no two components ever contribute to the color of a single pixel.

WPF は「画家のアルゴリズム」の描画モデルを使用します。WPF uses a "painter's algorithm" painting model. つまり、各コンポーネントをクリッピングする代わりに、各コンポーネントをディスプレイの背面から前面にレンダリングするように求められます。This means that instead of clipping each component, each component is asked to render from the back to the front of the display. これにより、各コンポーネントを前のコンポーネントの表示上にペイントできます。This allows each component to paint over the previous component's display. このモデルの利点は、複雑で部分的に透明な形状を持つことができる点です。The advantage of this model is that you can have complex, partially transparent shapes. 今日の最新のグラフィックス ハードウェアでは、このモデルは比較的高速です (User32/ GDI が作成された場合はそうではありませんでした)。With today’s modern graphics hardware, this model is relatively fast (which wasn’t the case when User32/ GDI were created).

前に述べたように、WPF の中心的な考え方は、より宣言的な"プロパティ中心"のプログラミング モデルに移行することです。As mentioned previously, a core philosophy of WPF is to move to a more declarative, "property centric" model of programming. ビジュアルシステムでは、これは興味深い場所のカップルに表示されます。In the visual system, this shows up in a couple of interesting places.

まず、保持モードのグラフィックシステムについて考えると、これは実際には、強制的な DrawLine/DrawLine 型モデルからデータ指向モデルに移動しています – 新しいライン()/新しいライン() 。First, if you think about the retained mode graphic system, this is really moving away from an imperative DrawLine/DrawLine type model, to a data oriented model – new Line()/new Line(). このデータ ドリブン レンダリングへの移行により、描画命令に対する複雑な操作をプロパティを使用して表現できます。This move to data driven rendering allows complex operations on the drawing instructions to be expressed using properties. 派生元の型Drawingは、実質的にレンダリングのオブジェクト モデルです。The types deriving from Drawing are effectively the object model for rendering.

次に、アニメーション システムを評価すると、ほぼ完全に宣言的なアニメーションが表示されます。Second, if you evaluate the animation system, you'll see that it is almost completely declarative. 開発者が次の場所や次の色を計算する代わりに、アニメーションをアニメーション オブジェクトのプロパティのセットとして表現できます。Instead of requiring a developer to compute the next location, or next color, you can express animations as a set of properties on an animation object. これらのアニメーションは、開発者またはデザイナーの意図を表現でき (このボタンをここから 5 秒後にそこに移動)、システムはそれを実現するための最も効率的な方法を決定できます。These animations can then express the intent of the developer or designer (move this button from here to there in 5 seconds), and the system can determine the most efficient way to accomplish that.


UIElementは、レイアウト、入力、イベントなどのコア サブシステムを定義します。UIElement defines core subsystems including Layout, Input, and Events.

レイアウトは、WPF の中心的な概念です。Layout is a core concept in WPF. 多くのシステムには、固定のレイアウト モデルのセット (HTML はレイアウト用の 3 つのモデル、フロー、絶対、およびテーブルをサポートしています) か、レイアウトのモデルがありません (User32 は実際には絶対配置のみをサポートします)。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 は、開発者やデザイナーが、命令型ロジックではなくプロパティ値によって駆動できる、柔軟で拡張可能なレイアウト モデルを必要とするという前提から始まりました。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. UIElementレベルでは、レイアウトの基本契約が導入されます – とパスArrangeを持Measureつ2つのフェーズモデル。At the UIElement level, the basic contract for layout is introduced – a two phase model with Measure and Arrange passes.

Measureを使用すると、コンポーネントがどの程度のサイズを取り、使用するかを決定できます。Measure allows a component to determine how much size it would like to take. 親要素が子要素にArrange対して、その最適な位置とサイズを決定するために複数回測定するように要求する場合が多いため、これは別のフェーズです。This is a separate phase from Arrange because there are many situations where a parent element will ask a child to measure several times to determine its optimal position and size. 親要素が子要素に測定を求めるという事実は、WPF のもう 1 つの重要な哲学を示しています。The fact that parent elements ask child elements to measure demonstrates another key philosophy of WPF – size to content. WPF のすべてのコントロールは、コンテンツの自然なサイズにサイズを設定する機能をサポートします。All controls in WPF support the ability to size to the natural size of their content. これにより、ローカライズが大幅に容易になり、要素のサイズが変更されるに従って要素の動的なレイアウトが可能になります。This makes localization much easier, and allows for dynamic layout of elements as things resize. フェーズArrangeを使用すると、親が各子の最終的なサイズを配置して決定できます。The Arrange phase allows a parent to position and determine the final size of each child.

多くの場合、WPF の出力側Visualと関連するオブジェクトについて話すのに多くの時間が費やされます。A lot of time is often spent talking about the output side of WPF – Visual and related objects. しかし、入力側にも膨大な量のイノベーションがあります。However there is a tremendous amount of innovation on the input side as well. おそらく、WPF の入力モデルで最も根本的な変更は、入力イベントがシステムを通じてルーティングされる一貫したモデルです。Probably the most fundamental change in the input model for WPF is the consistent model by which input events are routed through the system.

入力は、カーネル モードのデバイス ドライバーのシグナルとして発生し、Windows カーネルと User32 を含む複雑なプロセスを通じて正しいプロセスとスレッドにルーティングされます。Input originates as a signal on a kernel mode device driver and gets routed to the correct process and thread through an intricate process involving the Windows kernel and User32. 入力に対応する User32 メッセージが WPF にルーティングされると、WPF の未加工の入力メッセージに変換され、ディスパッチャーに送信されます。Once the User32 message corresponding to the input is routed to WPF, it is converted into a WPF raw input message and sent to the dispatcher. WPF では、生の入力イベントを複数の実際のイベントに変換できるため、配信が保証された低レベルのシステムで "MouseEnter" などの機能を実装できます。WPF allows for raw input events to be converted to multiple actual events, enabling features like "MouseEnter" to be implemented at a low level of the system with guaranteed delivery.

各入力イベントは、少なくとも 2 つのイベント ("プレビュー" イベントと実際のイベント) に変換されます。Each input event is converted to at least two events – a "preview" event and the actual event. WPF のすべてのイベントは、要素ツリーを通じてルーティングするという概念を持ちます。All events in WPF have a notion of routing through the element tree. イベントは、ツリー上のターゲットからルートまで移動する場合は"バブル"と言われ、ルートから始まり、ターゲットまで移動すると「トンネル」といわれます。Events are said to "bubble" if they traverse from a target up the tree to the root, and are said to "tunnel" if they start at the root and traverse down to a target. 入力プレビュー イベント トンネルを使用して、ツリー内の任意の要素がイベントをフィルタまたはアクションを実行できるようにします。Input preview events tunnel, enabling any element in the tree an opportunity to filter or take action on the event. 通常の (プレビュー以外の) イベントは、ターゲットからルートまでバブルします。The regular (non-preview) events then bubble from the target up to the root.

トンネルとバブルのフェーズの間で分割すると、キーボード アクセラレータなどの機能の実装は、複合世界で一貫した方法で動作します。This split between the tunnel and bubble phase makes implementation of features like keyboard accelerators work in a consistent fashion in a composite world. User32 では、サポートするすべてのアクセラレータを含む単一のグローバル テーブルを持つことでキーボード アクセラレータを実装します (Ctrl + N マッピングを "New")。In User32 you would implement keyboard accelerators by having a single global table containing all the accelerators you wanted to support (Ctrl+N mapping to "New"). アプリケーションのディスパッチャーで 、TranslateAcceleratorを呼び出して User32 の入力メッセージをスニッフィングし、登録されたアクセラレータに一致するものがあるかどうかを判断します。In the dispatcher for your application you would call TranslateAccelerator which would sniff the input messages in User32 and determine if any matched a registered accelerator. WPF では、システムが完全に "構成可能" であるため、この機能は機能しません。In WPF this wouldn’t work because the system is fully "composable" – any element can handle and use any keyboard accelerator. 入力用にこの 2 つのフェーズ モデルを使用すると、コンポーネントは独自の "TranslateAccelerator" を実装できます。Having this two phase model for input allows components to implement their own "TranslateAccelerator".

さらにこの 1 つの手順UIElementを実行するには、コマンド バインドの概念も紹介します。To take this one step further, UIElement also introduces the notion of CommandBindings. WPF コマンド システムを使用すると、開発者はコマンド エンド ポイント (実装するもの)ICommandの観点から機能を定義できます。The WPF command system allows developers to define functionality in terms of a command end point – something that implements ICommand. コマンド バインディングを使用すると、入力ジェスチャ (Ctrl+N) とコマンド (New) の間のマッピングを要素で定義できます。Command bindings enable an element to define a mapping between an input gesture (Ctrl+N) and a command (New). 入力ジェスチャとコマンド定義の両方が拡張可能で、使用時に一緒に配線できます。Both the input gestures and command definitions are extensible, and can be wired together at usage time. これにより、たとえば、エンド ユーザーがアプリケーション内で使用するキー バインドをカスタマイズできるようになるのは簡単です。This makes it trivial, for example, to allow an end user to customize the key bindings that they want to use within an application.

このトピックでは、WPF の "コア" 機能 - プレゼンテーションコア アセンブリに実装されている機能が焦点となっています。To this point in the topic, "core" features of WPF – features implemented in the PresentationCore assembly, have been the focus. WPF を構築する場合、基本部分 ([メジャー][配置] を使用したレイアウトのコントラクトなど) とフレームワークの各Grid部分 (特定のレイアウトの実装など) を明確に分離することが望ましい結果でした。When building WPF, a clean separation between foundational pieces (like the contract for layout with Measure and Arrange) and framework pieces (like the implementation of a specific layout like Grid) was the desired outcome. 目標は、必要に応じて外部の開発者が独自のフレームワークを作成できるように、スタック内の低い拡張性ポイントを提供することでした。The goal was to provide an extensibility point low in the stack that would allow external developers to create their own frameworks if needed.


FrameworkElement2つの異なる方法で見ることができます。FrameworkElement can be looked at in two different ways. WPF の下位層で導入されたサブシステムに対する一連のポリシーとカスタマイズを紹介します。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.

導入されるFrameworkElement主なポリシーは、アプリケーションのレイアウトに関するものです。The primary policy introduced by FrameworkElement is around application layout. FrameworkElementによって導入されたUIElement基本的なレイアウト コントラクトに基づいており、レイアウト作成者が一貫したプロパティ駆動型レイアウト セマンティクスのセットを持つことを容易にするレイアウトの "スロット" の概念を追加します。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. HorizontalAlignment VerticalAlignment、、MinWidthおよびMargin(いくつかの名前を付ける) などのプロパティはFrameworkElement、レイアウト コンテナー内の一貫した動作から派生したすべてのコンポーネントを与えます。Properties like HorizontalAlignment, VerticalAlignment, MinWidth, and Margin (to name a few) give all components derived from FrameworkElement consistent behavior inside of layout containers.

FrameworkElementまた、WPF のコア 層に含まれる多くの機能に対する API の公開が容易になります。FrameworkElement also provides easier API exposure to many features found in the core layers of WPF. たとえば、FrameworkElementメソッドを使用してアニメーションに直接アクセスBeginStoryboardできます。For example, FrameworkElement provides direct access to animation through the BeginStoryboard method. AStoryboardは、プロパティのセットに対して複数のアニメーションをスクリプト化する方法を提供します。A Storyboard provides a way to script multiple animations against a set of properties.

最も重要なのはFrameworkElement、データ バインディングとスタイルです。The two most critical things that FrameworkElement introduces are data binding and styles.

WPF のデータ バインディング サブシステムは、Windows フォームまたはASP.NETを使用してアプリケーションユーザー インターフェイス (UI)user interface (UI)を作成したユーザーには、比較的よく知っている必要があります。The data binding subsystem in WPF should be relatively familiar to anyone that has used Windows Forms or ASP.NET for creating an application ユーザー インターフェイス (UI)user interface (UI). これらの各システムでは、特定の要素の 1 つ以上のプロパティをデータにバインドする簡単な方法があります。In each of these systems, there is a simple way to express that you want one or more properties from a given element to be bound to a piece of data. WPF では、プロパティ バインディング、変換、およびリスト のバインドを完全にサポートしています。WPF has full support for property binding, transformation, and list binding.

WPF のデータ バインディングの最も興味深い機能の 1 つは、データ テンプレートの導入です。One of the most interesting features of data binding in WPF is the introduction of data templates. データ テンプレートを使用すると、データの視覚化方法を宣言によって指定できます。Data templates allow you to declaratively specify how a piece of data should be visualized. データにバインドできるカスタム ユーザー インターフェイスを作成する代わりに、問題を回避して、作成される表示をデータで決定させることができます。Instead of creating a custom user interface that can be bound to data, you can instead turn the problem around and let the data determine the display that will be created.

スタイル設定は、実際には軽量のデータ バインディングです。Styling is really a lightweight form of data binding. スタイル設定を使用すると、共有定義のプロパティのセットを要素の 1 つ以上のインスタンスにバインドできます。Using styling you can bind a set of properties from a shared definition to one or more instances of an element. スタイルは、明示的な参照 (プロパティをStyle設定) によって要素に適用されるか、またはスタイルを要素の CLR 型に関連付けることによって暗黙的に適用されます。Styles get applied to an element either by explicit reference (by setting the Style property) or implicitly by associating a style with the CLR type of the element.


コントロールの最も重要な機能は、テンプレートです。Control’s most significant feature is templating. WPF のコンポジション システムを保持モード レンダリング システムと考える場合、テンプレートを使用すると、コントロールはパラメーター化された宣言的な方法でレンダリングを記述できます。If you think about WPF’s composition system as a retained mode rendering system, templating allows a control to describe its rendering in a parameterized, declarative manner. AControlTemplateは、コントロールによって提供されるプロパティへのバインディングを使用して、子要素のセットを作成するスクリプトにすぎません。A ControlTemplate is really nothing more than a script to create a set of child elements, with bindings to properties offered by the control.

Controlには、Foregroundいくつかの名前を付けるストックBackgroundPaddingプロパティのセット 、、つまり、テンプレート作成者がコントロールの表示をカスタマイズするために使用できます。Control 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. インタラクション モデルは、コマンドのセット (ウィンドウの Close など) と入力ジェスチャへのバインド (ウィンドウの上隅にある赤い X をクリックするなど) を定義します。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).

この分割は、データ モデル (プロパティ)、相互作用モデル (コマンドとイベント)、および表示モデル (テンプレート) で、コントロールの外観と動作を完全にカスタマイズできます。This split between the data model (properties), interaction model (commands and events), and display model (templates) enables complete customization of a control’s look and behavior.

コントロールのデータ モデルの一般的な側面は、コンテンツ モデルです。A common aspect of the data model of controls is the content model. のようなButtonコントロールを見ると、"Content" という名前のプロパティが typeObjectであることがわかります。If you look at a control like Button, you will see that it has a property named "Content" of type Object. Windows フォームおよびASP.NETでは、通常、このプロパティは文字列になりますが、ボタンに配置できるコンテンツの種類が制限されます。In Windows Forms and ASP.NET, this property would typically be a string – however that limits the type of content you can put in a button. ボタンのコンテンツは、単純な文字列、複雑なデータ オブジェクト、または要素ツリー全体のいずれかです。Content for a button can either be a simple string, a complex data object, or an entire element tree. データオブジェクトの場合、データテンプレートは、表示を構築するために使用されます。In the case of a data object, the data template is used to construct a display.


WPF は、動的なデータ ドリブン 表示システムを作成できるように設計されています。WPF is designed to allow you to create dynamic, data driven presentation systems. システムのすべての部分は、動作を駆動するプロパティ セットを通じてオブジェクトを作成するように設計されています。Every part of the system is designed to create objects through property sets that drive behavior. データ バインディングはシステムの基本的な部分であり、すべての層に統合されています。Data binding is a fundamental part of the system, and is integrated at every layer.

従来のアプリケーションでは、ディスプレイを作成してから、データにバインドします。Traditional applications create a display and then bind to some data. WPF では、コントロールに関するあらゆる側面が、ある種のデータ バインディングによって生成されます。In WPF, everything about the control, every aspect of the display, is generated by some type of data binding. ボタン内に見つかったテキストは、ボタンの内部に構成されたコントロールを作成し、その表示をボタンの content プロパティにバインドすることによって表示されます。The text found inside a button is displayed by creating a composed control inside of the button and binding its display to the button’s content property.

WPF ベースのアプリケーションの開発を開始すると、非常に身近な感じがするはずです。When you begin developing WPF based applications, it should feel very familiar. Windows フォームやASP.NETを使用する場合とほぼ同じ方法で、プロパティの設定、オブジェクトの使用、およびデータ バインドを行うことができます。You can set properties, use objects, and data bind in much the same way that you can using Windows Forms or ASP.NET. WPF のアーキテクチャについて詳しく調べると、データをアプリケーションのコア ドライバーとして基本的に扱う、より豊富なアプリケーションを作成する可能性が高いことがわかります。With a deeper investigation into the architecture of WPF, you'll find that the possibility exists for creating much richer applications that fundamentally treat data as the core driver of the application.

関連項目See also