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. CLRCLRは生産性と堅牢性 (メモリ管理、エラー処理、共通型システムなどを含む) のある開発を行う数多くの機能を提供しますが、それらはコストの増加を招きます。The CLRCLR 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. (PresentationFramework、PresentationCore、および milcore) の図の赤のセクションではの大規模なコード部分WPFWPFします。The red sections of the diagram (PresentationFramework, PresentationCore, and milcore) are the major code portions of WPFWPF. これらのうち、1 つだけは、アンマネージ コンポーネント – milcore です。Of these, only one is an unmanaged component – milcore. 緊密な統合を有効にするには Milcore がアンマネージ コードで記述されたDirectXDirectXします。Milcore is written in unmanaged code in order to enable tight integration with DirectXDirectX. すべて表示WPFWPFを行う、DirectXDirectXエンジン、効率的なハードウェアとソフトウェア レンダリングすることができます。All display in WPFWPF is done through the DirectXDirectX engine, allowing for efficient hardware and software rendering. WPFWPF メモリと実行を細かく制御も必要です。also required fine control over memory and execution. Milcore 合成エンジンは、非常に機密性の高い、やの多くの利点をあきらめる必要なパフォーマンス、CLRCLRパフォーマンスを向上させます。The composition engine in milcore is extremely performance sensitive, and required giving up many advantages of the CLRCLR to gain performance.

WPF、.NET Framework 内の位置。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 メッセージをスレッド間の呼び出しを実行するために使用します。This works much like the familiar Win32Win32 message pump; in fact, the WPFWPF dispatcher uses User32 messages for performing cross thread calls.

本当に 2 つの主要で同時実行を検討する場合を理解する概念があるWPFWPF– ディスパッチャーとスレッド アフィニティ。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 スレッド モデルとの同期が保持されます。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.0OLE 2.0クリップボード、および Internet Explorer のすべて 1 つのスレッド アフィニティ (STA) の実行が必要です。The primary reason for this was interoperability – systems like OLE 2.0OLE 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. メッセージの例には、生の入力の通知 (マウスの移動)、framework 関数 (レイアウト)、またはユーザー コマンドが含まれます (このメソッドを実行)。Examples of messages include raw input notifications (mouse moved), framework functions (layout), or user commands (execute this method). 派生することによってDispatcherObject、作成する、 CLRCLR STA の動作を持つオブジェクトし、は指定のポインターをディスパッチャーに作成時にします。By deriving from DispatcherObject, you create a CLRCLR object that has STA behavior, and will be given a pointer to a dispatcher at creation time.


ビルドで使用されるプライマリ アーキテクチャ哲学の 1 つWPFWPFプロパティの基本設定がメソッドまたはイベントを超えました。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.

高度なプロパティ システムのプロパティによって駆動システムの詳細を確保するために、CLRCLR提供が必要でした。In order to have more of the system driven by properties, a richer property system than what the CLRCLR 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プロパティ式のシステムが閉じられるし、式はすべて、framework の一部として提供します。In this first release of WPFWPF, the property expression system is closed, and the expressions are all provided as part of the framework. 式は、プロパティ システムがデータ バインディング、スタイル設定がないか、継承はハード コーディングしていますがではなく、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 ほとんどの機能には、パブリックあるありませんので非常に軽量で柔軟なをするのには設計されていますAPIAPI公開し、保護されているコールバック関数に大きく依存します。Visual is designed to be extremely lightweight and flexible, so most of the features have no public APIAPI exposure and rely heavily on protected callback functions.

Visual エントリ ポイントは、実際に、WPFWPFコンポジション システム。Visual is really the entry point to the WPFWPF composition system. Visual マネージこれらの 2 つサブシステム間の接続ポイントは、APIAPIまさに、します。Visual is the point of connection between these two subsystems, the managed APIAPI and the unmanaged milcore.

WPFWPF milcore によって管理されるアンマネージ データ構造を走査して、データを表示します。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. VisualWPFWPF1 つのフィルターまたはいくつかの構成ノードを作成することがあります。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.

ダイアグラムで非常に顕著ではないもう 1 つの重要な詳細情報は、システムが実際に合成を実行する方法です。Another important detail that isn’t really noticeable in the diagram is how the system actually performs composition.

User32 でとGDIGDI、イミディ エイト モードのクリッピング システムで、システムが動作します。In User32 and GDIGDI, 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/GDIGDI作成された)。With today’s modern graphics hardware, this model is relatively fast (which wasn’t the case when User32/ GDIGDI 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 型モデルからモデルへの移行、データ指向 – 新しい行 ()/新しい 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 つのモデルがサポートしています。 フロー、絶対、およびテーブル) またはレイアウトのモデルのない (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). 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レベル、レイアウトの基本的なコントラクトが導入 – でモデルをフェーズ 2MeasureArrangeを渡します。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. 親要素が子要素を測定するよう要求するという事実がもう 1 つの重要な理念を示します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 が関係する複雑なプロセスのスレッドにルーティングされます。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 メッセージにルーティングされると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.

各入力イベントは、"preview"イベントと、実際のイベントには少なくとも 2 つのイベントに変換されます。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 でグローバル含む単一のテーブルをサポートするすべてのアクセラレータ (Ctrl + N の「新規」へのマッピング) することでキーボード アクセラレータを実装します。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. 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) とコマンドを (新規) 間のマッピングを定義する要素が有効にします。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– PresentationCore アセンブリに実装されている機能は、フォーカスされています。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 簡単に用意されていますAPIAPIの基本レイヤーについては、多くの機能への露出WPFWPFします。FrameworkElement also provides easier APIAPI 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. AStoryboardプロパティのセットに対して複数のアニメーションのスクリプトを作成する方法を提供します。A Storyboard provides a way to script multiple animations against a set of properties.

2 つの最も重要なことをFrameworkElement紹介はデータ バインドとスタイル。The two most critical things that FrameworkElement introduces are data binding and styles.

データ バインディング サブシステムWPFWPFが使用するユーザーにとって比較的馴染みがあるWindows フォームWindows FormsまたはASP.NETASP.NETアプリケーションを作成するユーザー インターフェイス (UI)user interface (UI)します。The data binding subsystem in WPFWPF should be relatively familiar to anyone that has used Windows フォームWindows Forms or ASP.NETASP.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.

データ バインディングの最も興味深い機能の 1 つWPFWPFデータ テンプレートの導入です。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プロパティ) のスタイルを関連付けることによって暗黙的にまたは、CLRCLR要素の型。Styles get applied to an element either by explicit reference (by setting the Style property) or implicitly by associating a style with the CLRCLR 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 ストック プロパティのセットを提供します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、型の場合は"Content"という名前のプロパティを使用しているが表示されますObjectします。If you look at a control like Button, you will see that it has a property named "Content" of type Object. Windows フォームWindows FormsASP.NETASP.NET、このプロパティは文字列である通常 – ボタンに配置することができますが、コンテンツの種類を制限します。In Windows フォームWindows Forms and ASP.NETASP.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. ボタンの内側にあるテキストは、ボタンの内部で構成されるコントロールを作成し、その表示をボタンの 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.

開発を開始すると、WPFWPFベースのアプリケーションでは、非常によくと考える必要があります。When you begin developing WPFWPF based applications, it should feel very familiar. オブジェクトを使用して、すべてのプロパティを設定することができ、データ バインドで同じ方法を使用できるWindows フォームWindows FormsまたはASP.NETASP.NETします。You can set properties, use objects, and data bind in much the same way that you can using Windows フォームWindows Forms or ASP.NETASP.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