Applikationsarchitektur modularer Rich Client-Anwendungen am Beispiel der

Windows Presentation Foundation

Jörg JoossMTC Architect

joerg.jooss@microsoft.comhttp://blogs.msdn.com/mtcmuc/

OOP 2009

2

Das SzenarioDesign Patterns, Composite Application Library (CAL)

Modulare Anwendung mit deutlicher höherer Software-Qualität überführen

3

Hintergrund: Qualitätsmerkmale

Maintainability: A set of attributes that bear on the effort needed to make specified modifications

(ISO 9126)

Stability Analyzability Changeability Testability

Iteration 0: „Die Applikation“

Demo

5

Iteration 0: Bestandsaufnahme

Beobachtungen

• Autonomous View (Anti-)Pattern: Applikationslogik und Präsentationslogik sind vermischt• Fehlende Abstraktionen• 95% der Applikationslogik liegen in einer Methode• Unit Testing sehr schwierig• Code bietet kaum Möglichkeiten zur Aufteilung zwischen Teams• Erweiterungen nach dem gleichen Entwicklungsansatz führen unweigerlich zum „Big Ball of Mud“

Software-Qualität

6

Iteration 1: Separate Presentation

Um den Big Ball of Mud zu verhindern, müssen wir die Präsentation vom Rest

der Anwendung trennen

Konkrete Design Patterns:• Model-View-Controller• Model-View-Presenter• Presentation Model

WPF und CAL geben jeweils keinen Ansatz vor – aber in WPF ist Presentation

Model sehr einfach zu realisieren

7

Hintergrund: Presentation ModelBenutzerinteraktion

View

Presentation Model

Business Logic

Businessness LogicAPI

Events

Commands Data Binding

8

Hintergrund: Commands

Receiver+Action<T>+Func<T, bool>

ICommand+Execute+CanExecute+CanExecuteChanged

DelegateCommand

+Execute+CanExecute+CanExecuteChanged

Invoker In CAL

In WPF

Iteration 1: Shell und Presentation Model

Code…

11

Iteration 1: Bestandsaufnahme

Beobachtungen

• View enthält keine Anwendungslogik und ist vom Presentation Model entkoppelt• Unit Testing des PM möglich (Unit Test als alternativer View)• Applikationslogik kann nach Belieben realisiert werden• Die Features von WPF (Datenbindung, Commands etc.) werden genutzt • Mehr als ein leeres Fenster haben wir jetzt aber nicht…

Software-Qualität

12

Iteration 2: File → Open → …?

Wie zeigen wir ein Dialogfenster an, ohne das Presentation Model ad absurdum zu

führen?

Einfachste Lösung: Indirektion – Auslagern in eine andere Komponente

„Service“ = Interface + Implementierung(en)

13

Iteration 2: File → Open → …? (cont’d)

Vermeide Abhängigkeiten zwischen Shell und Applikationskomponenten – wie aber

werden Informationen aus der Shell propagiert?

C#-Events helfen nicht –der Subscriber kennt den Publisher

bereits zur Buildtime

CAL stellt den Event Aggregator als Publish/Subscribe-Mechanismus bereit

14

Hintergrund: Event Aggregator

Publisher Subscriber

Publisher

Subscriber

Subscriber

Event Aggregator

CompositeWpfEvent<T>

CompositeWpfEvent<U>

Iteration 2: Events und Services

Code…

17

Iteration 2: Bestandsaufnahme

Beobachtungen

• Konsumenten von Ereignissen in der Shell bleiben durch Publish/Subscribe lose gekoppelt• Bereitstellung technischer Funktionen als Services erhöht Testbarkeit• FILECHANGEDEVENT ist momentan die einzige Gemeinsamkeit zwischen Provider (Shell) und

potentiellen Konsumenten• Es fehlt jedoch die Integration der Services

Software-Qualität

18

Iteration 3: Connecting the Dots

Wir wollen die losen Teile (Shell, Presentation Model, Services) verbinden,

zugleich aber die Verbindungen leicht ändern können

Dependency Injection-Container erlauben die Konstruktion von Objekten und deren

Abhängigkeiten

CAL bietet• Dependency Injection-Container

(Unity)• Bootstrapper

19

Kern eines Depedency

Injection Containers

Hintergrund: Dependency Injection

BuilderIService

ServiceImpl

Client<<creates>>

<<injects>>

Iteration 3: Bootstrapper und Dependency Injection

Code…

22

Iteration 3: Bestandsaufnahme

Beobachtungen

• Abhängigkeiten zwischen den Komponenten sind nicht hart codiert, sondern über Dependency Injection flexibel änderbar

• Testkonfigurationen können so das System entsprechend rekonfigurieren und Stubs, Fakes etc. verwenden

• Wir haben immer noch nur ein leeres Fenster…

Software-Qualität

23

Iteration 4: Module für die Massen

Wir wollen ein Konstrukt bereitstellen, das die eigentliche Anwendungslogik über alle Schichten kapselt – Module

Solche Module können auf verschiedene Weise geschnitten werden:• Infrastrukturkomponenten• Anwendungsfeatures• Subsysteme

CAL bietet die Infrastruktur zur Bereitstellung von Assemblies als Module

Iteration 4: Views und Services in einem Modul

Code…

26

Iteration 4: Bestandsaufnahme

Beobachtungen

• Ein Modul ist ein mehrschichtiger, in sich abgeschlossener Applikationsbaustein• Wie die Shell verwendet es PM, Commands, Pub/Sub und User Controls als Views• Hohe Kohäsion, niedrige Kopplung• Event Aggregator erleichtert Thread Marshalling• Die Implementierung verschiedener Module kann auf mehrere Teams aufgeteilt werden• Aber was macht eine Assembly eigentlich zum Modul?

Software-Qualität

27

Iteration 5: I, Module

Uns fehlt eine Möglichkeit das Modul zu initialisieren (Bootstrapper?)

Kennzeichnung von „Modulkomponenten“• Attribute• Interfaces• Basisklassen• Konvention

CAL sucht in einer Assembly nach Typen, die IMODULE implementieren

Iteration 5: Das IModule

Code…

30

Iteration 5: Bestandsaufnahme

Beobachtungen

• Ein IMODULE agiert wie ein modulspezifischer Bootstrapper • Wie in der Shell können so Abhängigkeiten im Modul per DI konfiguriert werden• Abhängigkeiten des Moduls werden von CAL injiziert• Wie aber bringen wir Module zur Ausführung?

Software-Qualität

31

Iteration 6: How to Be Found and Seen

Die Shell benötigt Mechanismen zum Finden von Modulen und Platzhalter zur

Anzeige von Views

Direkte Referenzen zwischen Shell und Modulen führen zu enger Kopplung

CAL bietet• Module Enumerators• Regions

32

Hintergrund: Regions

<ContentControl cal:RegionManager.RegionName=

"{x:Static fx:RegionNames.MainRegion}" />

Name der RegionTipp: Binden statt hart

codieren

ContentControls, Selectors, und

ItemControls können mit Regionen dekoriert

werden

Iteration 6: Die modulare Anwendung

Demo

35

Iteration 6: Bestandsaufnahme

Beobachtungen

• Die Shell muss Regionen zur Anzeige von Views vorsehen und benennen• Shell und Module/Views sind komplett entkoppelt, kennen jeweils nur

Regionenbezeichner und Ereignisse• Die Strategie zum Finden von Modulen ist austauschbar

Software-Qualität

36

Zusammenfassung

Modulare WPF-Anwendungen mit der Composite Application Library

Commands/Events

Services/Container

Bootstrapper

ModuleRegions/

Views

37

Ressourcen

Composite Application Guidance und CAL

• http://www.codeplex.com/CompositeWPF• http://msdn.microsoft.com/en-us/library/cc707819.aspx

patterns & practices Developer Center

• http://msdn.microsoft.com/en-us/practices/default.aspx

MTC München Team Blog (Code zur Session)

• http://blogs.msdn.com/mtcmuc/