Applikationsarchitektur modularer Rich Client-Anwendungen am Beispiel der Windows Presentation Foundation

Transkript

1 Applikationsarchitektur modularer Rich Client-Anwendungen am Beispiel der Windows Presentation Foundation Jörg Jooss MTC Architect OOP 2009

2 Das Szenario Rich Client-Anwendung (WPF, C#) von geringer Software-Qualität Design Patterns, Composite Application Library (CAL) Modulare Anwendung mit deutlicher höherer Software-Qualität überführen 2

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 3

4 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 5

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 6

7 Hintergrund: Presentation Model Benutzerinteraktion View Commands Data Binding Businessness Logic API Presentation Model Business Logic Events 7

8 Hintergrund: Commands Invoker In CAL ICommand +Execute +CanExecute +CanExecuteChanged DelegateCommand +Execute +CanExecute +CanExecuteChanged In WPF Receiver +Action<T> +Func<T, bool> 8

9 Iteration 1: Shell und Presentation Model Code

10 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 11

11 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) 12

12 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 13

13 Hintergrund: Event Aggregator Publisher Event Aggregator Subscriber CompositeWpfEvent<T> CompositeWpfEvent<U> Subscriber Publisher Subscriber 14

14 Iteration 2: Events und Services Code

15 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 17

16 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 18

17 Hintergrund: Dependency Injection Client <<creates>> Kern eines Depedency Injection Containers IService Builder ServiceImpl <<injects>> 19

18 Iteration 3: Bootstrapper und Dependency Injection Code

19 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 22

20 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 23

21 Iteration 4: Views und Services in einem Modul Code

22 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 26

23 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 27

24 Iteration 5: Das IModule Code

25 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 30

26 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 31

27 Hintergrund: Regions ContentControls, Selectors, und ItemControls können mit Regionen dekoriert werden <ContentControl cal:regionmanager.regionname= "{x:static fx:regionnames.mainregion}" /> Name der Region Tipp: Binden statt hart codieren 32

28 Iteration 6: Die modulare Anwendung Demo

29 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 35

30 Zusammenfassung Modulare WPF-Anwendungen mit der Composite Application Library Commands/ Events Services/ Container Bootstrapper Module Regions/ Views 36

31 Ressourcen Composite Application Guidance und CAL patterns & practices Developer Center MTC München Team Blog (Code zur Session) 37

32