Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Zelda Wicka Geändert vor über 10 Jahren
1
Applikationsarchitektur modularer Rich Client-Anwendungen am Beispiel der Windows Presentation Foundation Jörg Jooss MTC Architect joerg.jooss@microsoft.com http://blogs.msdn.com/mtcmuc/ OOP 2009
2
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
3
3 Hintergrund: Qualitätsmerkmale Maintainability: A set of attributes that bear on the effort needed to make specified modifications (ISO 9126) StabilityAnalyzabilityChangeabilityTestability
4
Iteration 0: Die Applikation
5
5 Iteration 0: Bestandsaufnahme 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 BeobachtungenSoftware-Qualität
6
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
7 Hintergrund: Presentation Model Benutzerinteraktion ViewView Presentation Model Business Logic Businessness Logic API Events Commands Data Binding
8
8 Hintergrund: Commands Receiver+Action<T> +Func +Func Receiver+Action<T> ICommand+Execute+CanExecute+CanExecuteChangedICommand+Execute+CanExecute+CanExecuteChangedDelegateCommand+Execute+CanExecute+CanExecuteChangedDelegateCommand+Execute+CanExecute+CanExecuteChanged InvokerInvoker In CAL In WPF
9
Iteration 1: Shell und Presentation Model
10
10 Iteration 1 – The Story So Far… Commands definiert: O PEN, C LOSE und E XIT Presentation Model (PM) implementiert E XIT implementiert Datenbindung zwischen Views und PM Neu MainWindow zur Shell reduziert Utility-Klassen entfernt Geändert oder entfernt
11
11 Iteration 1: Bestandsaufnahme 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… BeobachtungenSoftware-Qualität
12
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
13 Iteration 2: File Open …? (contd) 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
14 Hintergrund: Event Aggregator PublisherPublisherSubscriberSubscriber PublisherPublisher SubscriberSubscriber SubscriberSubscriber Event Aggregator CompositeWpfEvent<T>CompositeWpfEvent<T> CompositeWpfEvent<U>CompositeWpfEvent<U>
15
Iteration 2: Events und Services
16
16 Iteration 2 – The Story So Far… Funktionalität zum Öffnen von Dateien als Service gekapselt (IF ILE P ROVIDER und D IALOG F ILE P ROVIDER ) Das Ereignis F ILE C HANGED E VENT in neuer Assembly X ML E XPLORER S HARED definiert Property C URRENT F ILE zur Verwaltung der aktuell geöffneten Datei ergänzt löst F ILE C HANGED E VENT aus Presentation Model erfordert nun IE VENT A GGREGATOR und IF ILE P ROVIDER Neu O PEN und C LOSE implementiert Setzen C URRENT F ILE Geändert oder entfernt
17
17 Iteration 2: Bestandsaufnahme Konsumenten von Ereignissen in der Shell bleiben durch Publish/Subscribe lose gekoppelt Bereitstellung technischer Funktionen als Services erhöht Testbarkeit F ILE C HANGED E VENT ist momentan die einzige Gemeinsamkeit zwischen Provider (Shell) und potentiellen Konsumenten Es fehlt jedoch die Integration der Services BeobachtungenSoftware-Qualität
18
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
19 Kern eines Depedency Injection Containers Hintergrund: Dependency Injection BuilderBuilderIServiceIService ServiceImplServiceImpl ClientClient <<creates>> <<injects>>
20
Iteration 3: Bootstrapper und Dependency Injection
21
21 Iteration 3 – The Story So Far… Bootstrapper implementiert Dependency Injection-Container für Shell konfiguriert Neu Presentation Model und Shell nun DI friendly Startvorgang nun Application Boostrapper Container Shell, vorher Application Shell Geändert oder entfernt
22
22 Iteration 3: Bestandsaufnahme 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… BeobachtungenSoftware-Qualität
23
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
24
Iteration 4: Views und Services in einem Modul
25
25 Iteration 4 – The Story So Far… Neue Assembly X ML E XPLORER M ODULE XML-Verarbeitung in Service gekapselt Ursprüngliche XML-UI samt Ressourcen und Utility-Klassen in UserControl E XPLORER V IEW verlagert E XPLORER V IEW P RESENTATION M ODEL implementiert und für F ILE C HANGED E VENT registriert NeuGeändert oder entfernt
26
26 Iteration 4: Bestandsaufnahme 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? BeobachtungenSoftware-Qualität
27
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 IM ODULE implementieren
28
Iteration 5: Das IModule
29
29 Iteration 5: The Story So Far… IM ODULE implementiert IU NITY C ONTAINER als modul-interner Service Container für Modul konfiguriert NeuGeändert oder entfernt
30
30 Iteration 5: Bestandsaufnahme Ein IM ODULE 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? BeobachtungenSoftware-Qualität
31
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
32 Hintergrund: Regions Name der Region Tipp: Binden statt hart codieren Name der Region Tipp: Binden statt hart codieren ContentControls, Selectors, und ItemControls können mit Regionen dekoriert werden
33
Iteration 6: Die modulare Anwendung
34
34 Iteration 6: Abschluss IR EGION M ANAGER wird von CAL bereitgestellt R EGION N AMES IN X ML E XPLORER S HARED zur Verwaltung von Region-Ids C ONTENT C ONTROL zur Anzeige von Views in der Region M AIN R EGION in der Shell Neu IR EGION M ANAGER im Modul als Abhängigkeit ergänzt View in der Region M AIN R EGION angezeigt IM ODULE E NUMERATOR in der Shell zum Laden des Moduls Geändert oder entfernt
35
35 Iteration 6: Bestandsaufnahme 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 BeobachtungenSoftware-Qualität
36
36 Zusammenfassung Modulare WPF-Anwendungen mit der Composite Application Library Commands/ Events Services/ Container BootstrapperModule Regions/ Views
37
37 Ressourcen http://www.codeplex.com/CompositeWPF http://msdn.microsoft.com/en-us/library/cc707819.aspx Composite Application Guidance und CAL http://msdn.microsoft.com/en-us/practices/default.aspx patterns & practices Developer Center http://blogs.msdn.com/mtcmuc/ MTC München Team Blog (Code zur Session)
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.