WPF アーキテクチャWPF Architecture

このトピックでは、Windows Presentation Foundation (WPF) クラス階層のガイドツアーについて説明します。This topic provides a guided tour of the Windows Presentation Foundation (WPF) class hierarchy. WPFWPFの主なサブシステムの大部分について説明し、それらの相互作用について説明します。It covers most of the major subsystems of WPFWPF, and describes how they interact. また、WPFWPFのアーキテクトによって行われたいくつかの選択肢についても詳しく説明します。It also details some of the choices made by the architects of WPFWPF.


主要な WPFWPF プログラミングモデルは、マネージコードを通じて公開されます。The primary WPFWPF programming model is exposed through managed code. WPFWPF の設計フェーズの初期段階では、システムのマネージコンポーネントとアンマネージコンポーネントの間に行を描画する場所について、いくつかの論争がありました。Early in the design phase of WPFWPF 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.

WPFWPF の主要なコンポーネントを次の図に示します。The major components of WPFWPF are illustrated in the figure below. 図の赤色のセクション (プレゼンテーションフレームワーク、プレゼンテーションコア、およびミルコア) は、WPFWPFの主要なコード部分です。The red sections of the diagram (PresentationFramework, PresentationCore, and milcore) are the major code portions of WPFWPF. これらのうちの1つだけがアンマネージコンポーネント–ミルコアです。Of these, only one is an unmanaged component – milcore. ミルコアは、DirectX との緊密な統合を可能にするためにアンマネージコードで記述されています。Milcore is written in unmanaged code in order to enable tight integration with DirectX. WPFWPF のすべての表示は DirectX エンジンを介して行われるため、ハードウェアとソフトウェアを効率的にレンダリングできます。All display in WPFWPF is done through the DirectX engine, allowing for efficient hardware and software rendering. WPFWPF メモリと実行を細かく制御する必要もあります。also required fine control over memory and execution. 密度の高い合成エンジンは、パフォーマンスに大きな影響を与えます。そのため、パフォーマンスを得るためには、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.

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


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

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

WPFWPFの設計フェーズでは、目標は実行の1つのスレッドに移動しましたが、非スレッド "関連付け済み" モデルに移行することでした。During the design phase of WPFWPF, 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.dll スレッドモデルと同期した状態に保たれます。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.


WPFWPF の構築で使用される主要なアーキテクチャ思想の1つは、メソッドまたはイベントのプロパティを優先することでした。One of the primary architectural philosophies used in building WPFWPF 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. Microsoft .NET Framework にはINotifyPropertyChangeというインターフェイスがあります。これにより、オブジェクトは変更通知を発行できますが、これは省略可能です。The Microsoft .NET Framework has an interface, INotifyPropertyChange, which allows an object to publish change notifications, however it is optional.

WPFWPF には、DependencyObject の型から派生した、豊富なプロパティシステムが用意されています。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.

WPFWPF プロパティシステムの基礎は、プロパティ式の概念です。The foundation of the WPFWPF property system is the concept of a property expression. この WPFWPFの最初のリリースでは、プロパティ式システムが閉じられており、式はすべてフレームワークの一部として提供されています。In this first release of WPFWPF, 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. WPFWPF 要素は、合成とコンポーネントの再利用の原則に基づいて構築されます。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 の "expando" 機能に似ています。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 は、実際には WPFWPF コンポジションシステムへのエントリポイントです。Visual is really the entry point to the WPFWPF composition system. Visual は、マネージ API とアンマネージドミルコアの2つのサブシステム間の接続ポイントです。Visual is the point of connection between these two subsystems, the managed API and the unmanaged milcore.

WPFWPF は、ミルコアによって管理されているアンマネージデータ構造を走査することによってデータを表示します。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.

WPFWPFのプログラミング時には、このメッセージングプロトコルを使用して内部でコンポジションツリーに通信する Visual の要素と派生型を作成します。When programming WPFWPF, you create Visual elements, and derived types, which internally communicate to the composition tree through this messaging protocol. WPFWPF 内の各 Visual は、1つ、1つ、または複数の合成ノードを作成できます。Each Visual in WPFWPF 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. グラフィックス用語では、WPFWPF は保持されたレンダリングシステムを使用します。In graphics terms, WPFWPF 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.

図には実際にはわかりませんが、実際にはシステムが合成を実行する方法も重要です。Another important detail that isn’t really noticeable in the diagram is how the system actually performs composition.

User32.dll と 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. このシステムは、メモリの制約付きシステムで非常に適しています。影響を受けるコンポーネントに触れる必要があるのは、1つのピクセルの色に寄与する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.

WPFWPF は、"塗装のアルゴリズム" の描画モデルを使用します。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.dll/GDI が作成されたときには当てはまりません)。With today’s modern graphics hardware, this model is relatively fast (which wasn’t the case when User32/ GDI were created).

前述のように、WPFWPF の中核となる理念は、より宣言的な "プロパティ中心" のプログラミングモデルに移行することです。As mentioned previously, a core philosophy of WPFWPF 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 型モデルからデータ指向モデル (new Line ()/new Line ()) に移動します。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.

レイアウトは、WPFWPFでの主要な概念です。Layout is a core concept in WPFWPF. 多くのシステムでは、固定されたレイアウトモデルのセットがあります (HTML はレイアウト用に3つのモデル、flow、absolute、テーブル)、またはレイアウトのモデルがありません (User32.dll は絶対配置のみをサポートします)。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). WPFWPF、開発者やデザイナーが、命令型ロジックではなくプロパティ値によって駆動される柔軟性のある拡張可能なレイアウトモデルを必要としていることを前提としています。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 レベルでは、レイアウトの基本的なコントラクトが導入されます。これは、MeasureArrange 成功を持つ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. 親要素が子要素に測定を求めるという事実は、WPFWPF の別の重要な理念としてコンテンツに対するものです。The fact that parent elements ask child elements to measure demonstrates another key philosophy of WPFWPF – size to content. WPFWPF 内のすべてのコントロールは、そのコンテンツのサイズに合わせてサイズを変更する機能をサポートしています。All controls in WPFWPF 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.

多くの場合、WPFWPFVisual および関連オブジェクトの出力側について話します。A lot of time is often spent talking about the output side of WPFWPFVisual and related objects. しかし、入力側にも非常に多くのイノベーションがあります。However there is a tremendous amount of innovation on the input side as well. WPFWPF の入力モデルの最も基本的な変更は、入力イベントをシステム経由でルーティングするための一貫したモデルです。Probably the most fundamental change in the input model for WPFWPF is the consistent model by which input events are routed through the system.

入力は、カーネルモードデバイスドライバーの信号として生成され、Windows カーネルと User32.dll を含む複雑なプロセスを通じて、正しいプロセスとスレッドにルーティングされます。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.dll メッセージが WPFWPFにルーティングされると、WPFWPF 未加工の入力メッセージに変換され、ディスパッチャーに送信されます。Once the User32 message corresponding to the input is routed to WPFWPF, it is converted into a WPFWPF raw input message and sent to the dispatcher. WPFWPF を使用すると、未加工の入力イベントを複数の実際のイベントに変換できます。これにより、"MouseEnter" などの機能を、保証された配信によりシステムの低レベルで実装できます。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つのイベント ("preview" イベントと実際のイベント) に変換されます。Each input event is converted to at least two events – a "preview" event and the actual event. WPFWPF 内のすべてのイベントには、要素ツリーを通じたルーティングの概念があります。All events in WPFWPF 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.dll では、サポートするすべてのアクセラレータを含む単一のグローバルテーブルを使用して、キーボードアクセラレータを実装します (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.dll の入力メッセージをスニッフィングし、登録されているアクセラレータに一致したかどうかを判断します。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. WPFWPF では、システムが完全に "コンポーザブル" であるため、これは機能しません。すべての要素が任意のキーボードアクセラレータを処理して使用できます。In WPFWPF 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 CommandBindings の概念も紹介します。To take this one step further, UIElement also introduces the notion of CommandBindings. WPFWPF コマンドシステムを使用すると、開発者は、コマンドエンドポイント (ICommandを実装するもの) の観点から機能を定義できます。The WPFWPF 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.

トピック「」では、「WPFWPF –プレゼンテーションコアアセンブリに実装されている機能」の「コア」機能に焦点を当てました。To this point in the topic, "core" features of WPFWPF – features implemented in the PresentationCore assembly, have been the focus. WPFWPFの構築時には、基本要素 (メジャー配置によるレイアウトのコントラクトなど) とフレームワークの部分 (Gridなどの特定のレイアウトの実装など) の明確な分離が目的の結果でした。When building WPFWPF, 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.


FrameworkElement は、2つの異なる方法で確認できます。FrameworkElement can be looked at in two different ways. WPFWPFの下位層で導入されたサブシステムの一連のポリシーとカスタマイズについて説明します。It introduces a set of policies and customizations on the subsystems introduced in lower layers of WPFWPF. また、一連の新しいサブシステムも導入されています。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. HorizontalAlignmentVerticalAlignmentMinWidth、および 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 は、WPFWPFのコア層にある多くの機能に対する API の公開を容易にします。FrameworkElement also provides easier API exposure to many features found in the core layers of WPFWPF. たとえば、FrameworkElement は、BeginStoryboard メソッドを使用してアニメーションへの直接アクセスを提供します。For example, FrameworkElement provides direct access to animation through the BeginStoryboard method. Storyboard には、一連のプロパティに対して複数のアニメーションをスクリプト化する方法が用意されています。A Storyboard provides a way to script multiple animations against a set of properties.

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

WPFWPF のデータバインディングサブシステムは、アプリケーション ユーザー インターフェイス (UI)user interface (UI)を作成するために Windows フォームWindows Forms または ASP.NET を使用しているすべてのユーザーに対して比較的なじみがある必要があります。The data binding subsystem in WPFWPF should be relatively familiar to anyone that has used Windows フォーム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. WPFWPF は、プロパティのバインド、変換、およびリストバインドを完全にサポートしています。has full support for property binding, transformation, and list binding.

WPFWPF でのデータバインディングの最も興味深い機能の1つは、データテンプレートの導入です。One of the most interesting features of data binding in WPFWPF 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. ControlTemplate は、子要素のセットを作成するためのスクリプトにすぎず、コントロールによって提供されるプロパティへのバインドが含まれています。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 には、いくつかのストックプロパティ、ForegroundBackgroundPaddingが用意されています。これを使用すると、テンプレート作成者はコントロールの表示をカスタマイズできます。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. 相互作用モデルは、一連のコマンド (ウィンドウの [閉じる] など) と入力ジェスチャへのバインドを定義します (ウィンドウの上隅の赤い 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のようなコントロールを表示すると、Object型の "Content" という名前のプロパティがあることがわかります。If you look at a control like Button, you will see that it has a property named "Content" of type Object. Windows フォームWindows Forms と ASP.NET では、通常、このプロパティは文字列になりますが、ボタンに配置できるコンテンツの種類が制限されます。In Windows フォーム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.


WPFWPF は、データ駆動型の動的なプレゼンテーションシステムを作成できるように設計されています。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. WPFWPFでは、コントロールに関するすべての側面が、何らかの種類のデータバインディングによって生成されます。In WPFWPF, everything about the control, every aspect of the display, is generated by some type of data binding. ボタン内に表示されるテキストは、ボタン内に構築されたコントロールを作成し、その表示をボタンのコンテンツプロパティにバインドすることによって表示されます。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.

WPFWPF ベースのアプリケーションの開発を開始すると、非常になじみがあります。When you begin developing WPFWPF based applications, it should feel very familiar. Windows フォームWindows Forms または ASP.NET を使用する場合とほぼ同じ方法で、プロパティの設定、オブジェクトの使用、およびデータバインドを行うことができます。You can set properties, use objects, and data bind in much the same way that you can using Windows フォームWindows Forms or ASP.NET. WPFWPFのアーキテクチャについてさらに詳しく調査することで、アプリケーションのコアドライバーとしてデータを根本的に扱う、より豊富なアプリケーションを作成できる可能性があることがわかります。With a deeper investigation into the architecture of WPFWPF, 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