WPF-Architektur
Aktualisiert: November 2007
Dieses Thema enthält eine Einführung in die Klassenhierarchie von Windows Presentation Foundation (WPF). Es behandelt die meisten der wichtigsten Subsysteme von WPF und beschreibt deren Interaktion. Außerdem enthält dieses Thema ausführliche Erläuterungen zu einigen Entscheidungen der Architekten von WPF.
Dieses Thema enthält folgende Abschnitte.
- System.Object
- System.Threading.DispatcherObject
- System.Windows.DependencyObject
- System.Windows.Media.Visual
- System.Windows.UIElement
- System.Windows.FrameworkElement
- System.Windows.Controls.Control
- Zusammenfassung
- Verwandte Abschnitte
System.Object
Das primäre WPF-Programmiermodell wird mithilfe von verwaltetem Code bereitgestellt. Am Anfang der Entwurfsphase von WPF gab es einige Diskussionen darüber, wo die Linie zwischen den im System verwalteten Komponenten und den nicht verwalteten gezogen werden sollte. Die CLR stellt eine Reihe von Features bereit, die zu einer produktiveren und robusteren Entwicklung führen (einschließlich Speicherverwaltung, Fehlerbehandlung, allgemeines Typsystem usw.), die jedoch auch ihren Preis haben.
Die Hauptkomponenten von WPF werden in der folgenden Abbildung veranschaulicht. Die roten Abschnitte des Diagramms (PresentationFramework, PresentationCore und milcore) stellen die Hauptbestandteile des Codes von WPF dar. Von den hier dargestellten Komponenten wird lediglich eine Komponente nicht verwaltet – milcore. Milcore ist in einem nicht verwalteten Code geschrieben, um eine enge Integration mit DirectX zu ermöglichen. Alle Anzeigen in WPF erfolgen durch das DirectX-Modul, um ein effizientes Hardware- und Softwarerendering zu gewährleisten. WPF erforderte außerdem eine Feinsteuerung des Speichers und der Ausführung. Das Erstellungsmodul in milcore ist äußerst leistungsabhängig und erforderte im Sinne der Leistungsverbesserung die Aufgabe vieler CLR-Vorteile.
.png)
Die Kommunikation zwischen den verwalteten und nicht verwalteten Bereichen in WPF wird weiter unten in diesem Thema erläutert. Das restliche verwaltete Programmiermodell wird nachfolgend beschrieben.
System.Threading.DispatcherObject
Die meisten WPF-Objekte werden aus DispatcherObject abgeleitet, in dem die grundlegenden Konstrukte zur Handhabung von Parallelität und Threading bereitgestellt werden. WPF basiert auf einem vom Verteiler implementierten Nachrichtensystem. Die Funktionsweise ist mit der bekannten Meldungsverteilschleife in Win32 zu vergleichen. Tatsächlich verwendet der WPF-Verteiler User32-Meldungen zum Ausführen von threadübergreifenden Aufrufen.
Zur Behandlung des Themas Parallelität in WPF müssen tatsächlich zwei Kernkonzepte erfasst werden – Verteiler und Threadaffinität.
Während der Entwurfsphase von WPF bestand das Ziel darin, auf einen einzelnen Ausführungsthread, jedoch unter Verwendung eines "Affinitätsmodells" ohne Thread, umzusteigen. Eine Threadaffinität tritt auf, wenn eine Komponente die Identität des ausgeführten Threads verwendet, um irgendeinen Zustandstyp zu speichern. Die häufigste Verwendungsform dafür ist das Speichern eines Zustands im lokalen Threadspeicher (TLS). Threadaffinität erfordert, dass jeder logische Ausführungsthread nur von einem physischen Thread im Betriebssystem verwendet wird, was zu einer speicherintensiven Verarbeitung führen kann. Letztendlich wurde eine Übereinstimmung zwischen dem Threadingmodell in WPF und dem bestehenden User32-Threadingmodell erzielt, wonach ein einzelner Ausführungsthread mit Threadaffinität verwendet wird. Der Hauptgrund hierfür liegt in der Interoperabilität – Systeme wie OLE 2.0, die Zwischenablage und der Internet Explorer erfordern alle die Singlethread-Affinitätsausführung (STA, Single Thread Affinity).
Wenn Sie Objekte mit STA-Threading einsetzen, benötigen Sie eine Möglichkeit zur Kommunikation zwischen den Threads und zur Validierung des korrekten Threads. Dies ist die Rolle des Verteilers. Der Verteiler ist ein Basissystem zur Verteilung von Meldungen mit mehreren priorisierten Warteschlangen. Zu den Meldungen gehören z. B. Benachrichtigungen für unformatierte Eingaben (Mausbewegung), Framework-Funktionen (Layout) oder Benutzerbefehle (diese Methode ausführen). Durch das Ableiten aus DispatcherObject erstellen Sie ein CLR-Objekt mit STA-Verhalten, das zum Zeitpunkt der Erstellung mit einem Zeiger auf den Verteiler versehen wird.
System.Windows.DependencyObject
Eine der primären Strategien bei der Entwicklung der WPF-Architektur war die Bevorzugung von Eigenschaften vor der Verwendung von Methoden oder Ereignissen. Eigenschaften sind deklarativ und ermöglichen Ihnen eine einfachere Angabe von Absichten anstatt von Aktionen. Außerdem wird dadurch ein modell- oder datengesteuertes System für die Anzeige der Benutzerflächeninhalte unterstützt. Diese Philosophie hatte den beabsichtigten Effekt, dass mehr Eigenschaften erstellt werden als gebunden werden können, um das Verhalten einer Anwendung besser steuern zu können.
Um mehr Systemkomponenten eigenschaftengesteuert verwenden zu können, war ein umfassenderes Eigenschaftensystem als das in der CLR bereitgestellte erforderlich. Ein einfaches Beispiel für diese Leistungsfähigkeit sind Änderungsbenachrichtigungen. Um bidirektionale Bindungen zu ermöglichen, müssen beide Seiten der Bindung Änderungsbenachrichtigungen unterstützen. Um das Verhalten an die Eigenschaftenwerte zu binden, müssen Sie benachrichtigt werden, sobald sich der Eigenschaftenwert ändert. Das Microsoft .NET Framework verfügt über die Schnittstelle INotifyPropertyChange, mit der Objekte Änderungsbenachrichtigungen veröffentlichen können; die Verwendung ist jedoch optional.
WPF stellt ein umfangreicheres Eigenschaftensystem bereit, das vom DependencyObject-Typ abgeleitet wird. Das Eigenschaftensystem ist insofern wirklich ein Abhängigkeitseigenschaftensystem, als es die Abhängigkeiten zwischen den Eigenschaftsausdrücken erfasst und im Falle von Abhängigkeitsänderungen die Eigenschaftenwerte automatisch erneut überprüft. Wenn Sie z. B. eine Eigenschaft verwenden, die Werte erbt (z. B. FontSize), wird das System automatisch aktualisiert, wenn sich die Eigenschaft in einem übergeordneten Element des Elements ändert, das den Wert erbt.
Das WPF-Eigenschaftensystem basiert auf dem Konzept eines Eigenschaftsausdrucks. In dieser ersten Version von WPF ist das Eigenschaftsausdrucksystem in sich geschlossen, und die Ausdrücke werden alle als Bestandteil des Frameworks bereitgestellt. Ausdrücke sind der Grund dafür, warum das Eigenschaftensystem keine hartcodierte Datenbindung, Formatierung oder Vererbung aufweist, sondern diese in höheren Ebenen im Framework bereitstellt.
Das Eigenschaftensystem ermöglicht außerdem das Speichern von Eigenschaftenwerten in einem kompakten Speicherformat. Da Objekte über Dutzende (wenn nicht über Hunderte) von Eigenschaften verfügen können und sich die meisten Werte im Standardzustand (geerbt, von Stilen festgelegt usw.) befinden, besteht keine Notwendigkeit, die gesamten Eigenschaften für jede Instanz eines Objekts definieren zu müssen.
Als letztes neues Feature des Eigenschaftensystems sind die angefügten Eigenschaften zu nennen. WPF-Elemente sind auf dem Prinzip der Erstellung und der Wiederverwendung von Komponenten aufgebaut. Es ist häufig der Fall, dass ein enthaltendes Element (z. B. ein Grid-Layoutelement) zusätzliche Daten zu untergeordneten Elementen benötigt, um sein Verhalten zu steuern (z. B. die Zeilen-/Spalteninformationen). Anstatt alle diese Eigenschaften mit jedem einzelnen Element zu verknüpfen, ist es für jedes beliebige Objekt möglich, jedem anderen Objekt Eigenschaftendefinitionen bereitzustellen. Dies ist mit den expando-Features von JavaScript zu vergleichen.
System.Windows.Media.Visual
Nachdem ein System definiert ist, besteht der nächste Schritt darin, Bildelemente auf den Bildschirm zu zeichnen. Mithilfe der Visual-Klasse kann eine Struktur von visuellen Objekten erstellt werden, in der jedes Objekt optional Zeichnungsanweisungen und Metadaten zum Rendern dieser Anweisungen (Clipping, Transformation usw.) enthalten kann. Visual wurde im Hinblick auf eine äußerst einfache und flexible Lösung entwickelt, sodass die meisten Features keine öffentliche API-Verfügbarkeit aufweisen und stark von geschützten Rückruffunktionen abhängen.
Visual ist tatsächlich der Einstiegspunkt zum WPF-Erstellungssystem. Visual ist der Verbindungspunkt zwischen diesen beiden Subsystemen: der verwalteten API und dem nicht verwalteten milcore.
WPF zeigt Daten an, indem die nicht verwalteten Datenstrukturen (in milcore verwaltet) durchlaufen werden. Diese Strukturen werden Strukturknoten genannt und stellen eine hierarchische Anzeigestruktur mit Renderinganweisungen in jedem Knoten dar. Auf diese Struktur (auf der rechten Seite der folgenden Abbildung dargestellt) kann nur über ein Nachrichtenprotokoll zugegriffen werden.
Bei der Programmierung von WPF erstellen Sie Visual-Elemente und abgeleitete Typen, die intern mithilfe dieses Nachrichtenprotokolls mit der zusammengesetzten Struktur kommunizieren. Jedes Visual-Element in WPF kann einen, keinen oder mehrere Strukturknoten erstellen.
.png)
An dieser Stelle ist ein äußerst wichtiges architektonisches Detail zu beachten: Die gesamte Struktur der visuellen Elemente und Zeichnungsanweisungen wird im Cache gespeichert. Im Hinblick auf Grafiken verwendet WPF ein Renderingsystem mit Speichermodus. Dadurch ist es dem System möglich, Zeichnungen mit hohen Aktualisierungsraten erneut darzustellen, ohne das Erstellungssystem durch Rückrufe an den Benutzercode blockieren zu müssen. Auf diese Weise können Sie dem Anschein einer nicht reagierenden Anwendung vorbeugen.
Ein anderes wichtiges, im Diagramm nicht wirklich erkennbares Detail, ist die Art und Weise, wie das System tatsächlich die Zusammensetzung der Komponenten ausführt.
In User32 und GDI verwendet das System ein Clippingsystem mit unmittelbarem Modus. Wenn eine Komponente gerendert werden muss, erstellt das System eine Clippinggrenze, außerhalb derer die Komponente keine Pixel anfassen darf. Daraufhin wird die Komponente aufgefordert, die Bildelemente in dieses Feld zu zeichnen. Das System kann sehr gut in Systemen mit eingeschränktem Speicher eingesetzt werden, da im Fall von Änderungen nur die davon betroffene Komponente zu ändern ist. Die Farbe eines einzelnen Pixels wird niemals von zwei Komponenten beeinflusst.
WPF verwendet ein Zeichnungsmodell mit einem Maleralgorithmus. Dies bedeutet, dass die einzelnen Komponenten nicht geclippt werden, sondern einzeln vom Hintergrund bis hin zum Vordergrund der Anzeige gerendert werden. Dadurch kann jede Komponente die Anzeige der vorherigen Komponente übermalen. Der Vorteil dieses Modells ist, dass komplexe Formen verwendet werden können, die teilweise transparent sind. Mit der heutigen modernen Grafikhardware ist dieses Modell relativ schnell (was nicht der Fall war, als User32/GDI entwickelt wurde).
Wie bereits erwähnt, sieht die Kernphilosophie von WPF vor, ein eher deklaratives, eigenschaftenorientiertes Programmiermodell einzusetzen. Im visuellen System zeigt sich dies an ein paar interessanten Stellen.
Erstens: Wenn Sie das Grafiksystem mit Speichermodus betrachten, bewegt sich dieses tatsächlich weg von einem imperativen DrawLine/DrawLine-Typmodell hin zu einem datenorientierten Modell – new Line()/new Line(). Der Schritt hin zu einem datengesteuerten Rendering ermöglicht es, dass komplexe Vorgänge in den Zeichnungsanweisungen anhand von Eigenschaften angegeben werden können. Die aus Drawing abgeleiteten Typen sind gewissermaßen das zu rendernde Objektmodell.
Zweitens: Wenn Sie das Animationssystem näher betrachten, werden Sie feststellen, dass es fast vollständig deklarativ ist. Anstatt einen Entwickler für die Berechnung der nächsten Position oder Farbe zu benötigen, können Sie Animationen als eine Gruppe von Eigenschaften für ein Animationsobjekt angeben. Diese Animationen geben dann die Absicht des Entwicklers oder Designers an (diese Schaltfläche von hier nach dort in 5 Sekunden bewegen), und das System ermittelt den effizientesten Weg zur Erreichung dieses Ziels.
System.Windows.UIElement
UIElement definiert Kernsubsysteme einschließlich Layouts, Eingaben und Ereignisse.
Layouts stellen ein Kernkonzept in WPF dar. Viele Systeme enthalten entweder einen festen Satz an Layoutmodellen (HTML unterstützt drei Layoutmodelle: fortlaufende, absolute und Tabellen) oder keine Layoutmodelle (User32 unterstützt nur die absolute Positionierung). Die Vorgaben für WPF gingen von der Annahme aus, dass Entwickler und Designer ein flexibles, erweiterbares Layoutmodell benötigten, das nicht von einer imperativen Logik, sondern von Eigenschaftenwerten gesteuert werden sollte. Auf der UIElement-Ebene wird der Basisvertrag für das Layout eingeführt – ein Zweiphasenmodell mit Measure-Durchläufen und Arrange-Durchläufen.
Anhand von Measure kann eine Komponente seine Größe bestimmen. Hierbei handelt es sich um eine von Arrange getrennte Phase, da viele Situationen auftreten können, in denen ein übergeordnetes Element ein untergeordnetes Element auffordert, mehrere Measures zur Ermittlung seiner optimalen Position und Größe auszuführen. Die Tatsache, dass untergeordnete Elemente von übergeordneten Elementen zur Durchführung von Measures aufgefordert werden, verdeutlicht eine andere Schlüsselphilosophie von WPF – Das Anpassen der Größe an den Inhalt. Alle Steuerelemente in WPF unterstützen die Fähigkeit, sich an die natürliche Größe ihres Inhalts anzupassen. Dies führt zu einer einfacheren Lokalisierung und ermöglicht aufgrund der Größenanpassung ein dynamisches Elementlayout. Anhand der Arrange-Phase kann ein übergeordnetes Element jedes untergeordnete Element positionieren und dessen endgültige Größe bestimmen.
Der Aspekt der Ausgabe in WPF, nämlich die Ausgabe der Visual-Objekte und der verwandten Objekte, wird häufig sehr zeitintensiv besprochen. Es gibt jedoch auch auf der Seite der Eingabe enorme Innovationen zu verzeichnen. Eine der grundlegendsten Änderungen im Eingabemodell von WPF ist wahrscheinlich das einheitliche Modell, durch das Eingabeereignisse im System weitergeleitet werden.
Eingaben entstehen als ein Signal in einem Gerätetreiber im Kernelmodus und werden an den korrekten Prozess und Thread mithilfe eines komplexen Prozesses, der den Kernel von Windows und User32 einbezieht, weitergeleitet. Nachdem für die Eingabe die entsprechende User32-Meldung an WPF weitergeleitet wurde, wird sie in eine unformatierte WPF-Eingabemeldung konvertiert und an den Verteiler übermittelt. In WPF können unformatierte Eingabeereignisse in mehrere tatsächliche Ereignisse konvertiert werden, wodurch Features wie "MouseEnter" auf einer niedrigen Systemebene mit Zustellungsgewährleistung implementiert werden können.
Jedes Eingabeereignis wird in mindestens zwei Ereignisse konvertiert – in ein "Vorschauereignis" und in das tatsächliche Ereignis. Alle WPF-Ereignisse können innerhalb der Elementstruktur weitergeleitet werden. Ereignisse steigen "in Blasen" auf, wenn sie von einem Ziel entlang der Struktur nach oben bis zum Stamm traversieren. Sie arbeiten nach dem Tunnelprinzip, wenn sie vom Stamm ausgehend nach unten zu einem Ziel traversieren. Eingabenvorschauereignisse nutzen das Tunnelprinzip, wodurch jedes in der Struktur enthaltene Element das Ereignis filtern oder eine Ereignismaßnahme ergreifen kann. Die regulären Ereignisse (keine Vorschauereignisse) steigen dann vom Ziel hoch zum Stamm auf.
Diese Unterteilung zwischen der Tunnel- und Aufstiegsphase ermöglicht eine einheitliche Implementierung von Features (z. B. von Zugriffstasten) in einer gemischten Umgebung. In User32 würden Sie Zugriffstasten anhand einer einzelnen globalen Tabelle implementieren, die alle zu unterstützenden Zugriffstasten (Strg+N mit "Neu" verknüpft) enthält. In dem Verteiler Ihrer Anwendung würden Sie TranslateAccelerator aufrufen, der die Eingabemeldungen in User32 einliest und ermittelt, ob eine Übereinstimmung mit einer registrierten Zugriffstaste besteht. In WPF würde dies nicht funktionieren, da das System vollständig zusammensetzbar ist, d. h., jedes Element kann jede beliebige Zugriffstaste verarbeiten und verwenden. Dieses eingabenrelevante Zweiphasenmodell ermöglicht es Komponenten, den eigenen "TranslateAccelerator" zu implementieren.
Darüber hinaus führt UIElement das Konzept der CommandBindings ein. Mithilfe des WPF-Befehlssystem können Entwickler Funktionalitäten in Form von Befehlsendpunkten definieren – etwas, wodurch ICommand implementiert wird. Befehlsbindungen ermöglichen, dass Elemente die Zuordnung einer Eingabeaktion (Strg+N) zu einem Befehl (Neu) definieren können. Sowohl Eingabeaktionen als auch Befehlsdefinitionen sind erweiterbar und können zum Zeitpunkt der Verwendung miteinander verknüpft werden. Dadurch können Endbenutzer z. B. die in einer Anwendung zu verwendenden Tastenbindungen überaus einfach anpassen.
In diesem Thema wurden bislang hauptsächlich die WPF-Kernfeatures, d. h. die in der PresentationCore-Assembly implementierten Features, veranschaulicht. Das gewünschte Ergebnis beim Aufbau von WPF war eine klare Trennung zwischen den grundlegenden Bestandteilen (z. B. der Vertrag für das Layout mit Measure und Arrange) und den Framework-Bestandteilen (z. B. der Implementierung eines bestimmten Layouts wie Grid). Das Ziel bestand darin, einen Erweiterungspunkt weit unten im Stapel bereitzustellen, durch den externe Entwickler ihre eigenen Frameworks bei Bedarf erstellen könnten.
System.Windows.FrameworkElement
FrameworkElement kann auf zwei verschiedene Weisen betrachtet werden. Es umfasst eine Reihe von Richtlinien und Anpassungen für die Subsysteme, die in niedrigeren Ebenen von WPF enthalten sind. Außerdem führt es eine Reihe neuer Subsysteme ein.
Die primäre Richtlinie in FrameworkElement bezieht sich auf das Anwendungslayout. FrameworkElement baut auf dem von UIElement eingeführten grundlegenden Layoutvertrag auf und fügt das Konzept eines "Layoutplatzes" hinzu, was dazu führt, dass die Layoutautoren leichter auf eine einheitliche eigenschaftengesteuerte Layoutsemantik zugreifen können. Eigenschaften wie HorizontalAlignment, VerticalAlignment, MinWidth und Margin (um nur ein paar zu nennen) weisen allen Komponenten, die aus FrameworkElement abgeleitet sind, ein einheitliches Verhalten innerhalb eines Layoutcontainers zu.
Mit FrameworkElement ist es auch einfacher, eine API vielen der in den Kernebenen von WPF enthaltenen Features zur Verfügung zu stellen. Zum Beispiel stellt FrameworkElement einen Direktzugriff auf Animationen durch die BeginStoryboard-Methode bereit. Ein Storyboard bietet eine Möglichkeit, mehrere Animationen in einem Skript eigenschaftsabhängig anzugeben.
Die beiden entscheidendsten Features von FrameworkElement sind Datenbindung und Stile.
Das in WPF enthaltene Datenbindungssubsystem müsste jedem relativ bekannt sein, der eine Benutzeroberfläche (user interface, UI) für eine Anwendung erstellt hat und dafür Windows Forms oder ASP.NET verwendet hat. In jedem dieser Systeme gibt es eine einfache Möglichkeit, um auszudrücken, dass eine oder mehrere Eigenschaften eines bestimmten Elements an bestimmte Daten gebunden werden sollen. Eigenschaftenbindung, Transformation und Listenbindung werden in WPF in vollem Umfang unterstützt.
Eines der interessantesten Features der Datenbindung in WPF ist die Einführung von Datenvorlagen. Datenvorlagen ermöglichen eine deklarative Angabe darüber, wie Daten visualisiert werden sollen. Anstatt eine benutzerdefinierte Benutzeroberfläche zu erstellen, die an Daten gebunden werden kann, können Sie das Problem von der anderen Seite angehen, indem Sie die Daten die zu erstellende Anzeige bestimmen lassen.
Das Formatieren stellt eine einfache Form der Datenbindung dar. Anhand der Formatierung können Sie die in einer freigegebenen Definition enthaltenen Eigenschaften an eine oder mehrere Elementinstanzen binden. Stile können auf ein Element angewendet werden, indem sie entweder explizit (durch die Einstellung der Style-Eigenschaft) oder implizit, durch die Verknüpfung eines Stils mit dem CLR-Typ des Elements, angegeben werden.
System.Windows.Controls.Control
Das bedeutendste Feature von Control ist die Vorlagenverwendung. Betrachten Sie das Erstellungssystem in WPF als Renderingsystem mit Speichermodus, in dem Steuerelemente ihr Rendering anhand von Vorlagen in einer parametrisierten, deklarativen Form darstellen können. Eine ControlTemplate ist lediglich ein Skript zur Erstellung von untergeordneten Elementen, das Bindungen zu den im Steuerelement enthaltenen Eigenschaften vorsieht.
Control stellt eine Reihe von vordefinierten Eigenschaften wie Foreground, Background, Padding (um nur einige zu nennen) bereit, die von den Autoren der Vorlagen verwendet werden können, um die Anzeige eines Steuerelements anzupassen. Die Implementierung eines Steuerelements umfasst ein Datenmodell und ein Interaktionsmodell. Das Interaktionsmodell definiert eine Reihe von Befehlen (z. B. für das Schließen eines Fensters) sowie Bindungen zu Eingabeaktionen (z. B. wenn auf das rote X der oberen Fensterecke geklickt wird). Das Datenmodell stellt Eigenschaften bereit, um entweder das Interaktionsmodell oder die Anzeige (wird von der Vorlage bestimmt) anpassen zu können.
Durch diese Unterteilung in Datenmodell (Eigenschaften), Interaktionsmodell (Befehle und Ereignisse) und Anzeigemodell (Vorlagen) können das Erscheinungsbild und das Verhalten eines Steuerelements vollständig angepasst werden.
Ein allgemeiner Aspekt des Datenmodells von Steuerelementen ist das Inhaltsmodell. Wenn Sie z. B. das Steuerelement Button, betrachten, stellen Sie fest, dass es über die Eigenschaft namens "Content" vom Typ Object verfügt. In Windows Forms und ASP.NET würde es sich bei dieser Eigenschaft normalerweise um eine Zeichenfolge handeln, was jedoch den Typ des Inhalts einschränkt, mit dem eine Schaltfläche versehen werden kann. Der Inhalt einer Schaltfläche kann entweder eine einfache Zeichenfolge, ein komplexes Datenobjekt oder eine komplette Elementstruktur sein. Wenn es sich um ein Datenobjekt handelt, wird für die Erstellung der Anzeige eine Datenvorlage verwendet.
Zusammenfassung
WPF ist für die Erstellung von dynamischen, datengesteuerten Präsentationssystemen konzipiert. Die einzelnen Bestandteile des Systems eignen sich für die Objekterstellung anhand von Eigenschaften, die das Verhalten steuern. Datenbindung ist ein wesentlicher und auf jeder Ebene integrierter Systembestandteil.
Herkömmliche Anwendungen erstellen eine Anzeige und daraufhin eine Bindung zu bestimmten Daten. In WPF werden sämtliche Informationen zu einem Steuerelement sowie jeder Aspekt der Anzeige durch eine bestimmte Art der Datenbindung generiert. Der in einer Schaltfläche enthaltene Text wird angezeigt, indem in der Schaltfläche ein zusammengesetztes Steuerelement erstellt und dessen Anzeige an die Inhaltseigenschaft der Schaltfläche gebunden wird.
Wenn Sie mit der Entwicklung von Anwendungen auf der Basis von WPF beginnen, wird Ihnen etliches bereits vertraut sein. Die Verfahren zum Festlegen von Eigenschaften, zum Verwenden von Objekten und zum Binden von Daten sind in vielerlei Hinsicht den entsprechenden Verfahren in Windows Forms oder ASP.NET ähnlich. Wenn Sie sich mit der Architektur von WPF eingehender auseinandersetzen, werden Sie die Möglichkeiten zur Erstellung von komplexeren Anwendungen entdecken, in denen Daten im Wesentlichen als Kernantrieb der Anwendung behandelt werden.