Architektur Pattern Organisation und Interaktion zwischen den Komponenten
Einteilung Es gibt verschiedenste Architekturmuster welche abhängig vom Projektumfang und -umfeld sinnvoll verwendet werden: Model-View-Controller, Model-View-ViewModel Multitier- und Layer- Architektur Verteilte Systeme Domain Driven Design, Hexagonale Architektur Web Bereich, JavaEE,.Net, Client-Server Service-Oriented (Prozess-Orientiert), Peer-to-Peer,... Rich Client, GUI Applikation Innerer Aufbau von Softwarekomponenten Reflection, Inverstion of Control, Dependency Injection,... Adaptive (Komponenten) Systeme, Entkoppelung
Model View Controller Modell-Präsentation-Steuerung
Problem/Umfeld Verschiedene Nutzer oder Sichten der gleichen Daten View 1: Pie Chart ASD: ASD: 95 95 CJA: CJA: 64 64 FBU: FBU: 109 109 JPQ: JPQ: 152 152 SGD: SGD: 204 204 View 2: Bar Chart ASD 95 15% CJA 64 10% FBU 109 JPQ 152 18% SGD 33% 204 24% View 3: Spread Sheet
Problem/Umfeld Zur Präsentation eines Models werden ein oder mehrere Views erzeugt. Jedes View muss sicherstellen, dass es den aktuellen Zustand des Models korrekt wiedergibt. Lösung: Observer Jedes View meldet sich beim Model als Observer an. Wenn sich das Model ändert, benachrichtigt es alle Observer. Dadurch erhalten die Views die Möglichkeit, sich anzupassen. Problem: User-Events
Model-View-Controller Drei Teile Ausgabe Benutzer Benutzer Eingabe Model View Controller View Controller Controller Model Model Daten und ihre Verarbeitung Präsentation der Daten Benutzer-Eingaben Entkoppelung der verschiedenen Teile der Applikation mehr Flexibilität
View Stellt die Daten / Informationen dar (Präsentation) Leitet Benutzereingaben an den Controller weiter Kennt Controller und Model Wird vom Model über Datenänderungen informiert (Observer)
Controller Verwaltet eine oder ev. mehrere Views Nimmt von der View die Benutzeraktionen (Events) entgegen und wertet sie aus. Leitet die Aktionen an das Model weiter Wird ev. vom Model über Datenänderungen informiert (Observer) um auf Zustandsänderungen zu reagieren. Kann die View steuern (Ansicht wechseln, auf andere Seite wechseln)
Model Der Funktionale Teil der Applikation Zuständig für die Daten-Verwaltung und die Business Logik Observable Kennt die angemeldeten Observer (Views und Controller) Benachrichtigt alle Observer über Daten- oder Zustands-Änderungen
Funktionaler Ablauf
MVC mit Observable / Observer
Event Handling im MVC Pattern
Verweis auf andere Muster Observer Wird Model View Presenter im MVC üblicherweise benutzt View agiert nur mit Presenter, dieser ist Bindeglied zwischen Model und View steuert die logischen Abläufe zwischen den beiden anderen. Model View ViewModel MVP mit Command- und Data-Binding
Offene Punkte Aufteilung der Logik zwischen Controller und Model? Ansiedlung von Formatierung und Internationalisierung? Ort für die Validierung der BenutzerEingaben? Werden in verschiedenen Implementierungen / Frameworks unterschiedlich gelöst.
Model View ViewModel Data-Binding / Model View Presenter
Umfeld/Zweck Analog zu MVC Pattern Trennung von Darstellung und Logik Vereinfachung der Schnittstelle durch DataBinding
Eigenschaften Auftrennung in separate Teile Die View kapselt den UI Aufbau (z.b. HTML5). Das ViewModel kapselt die Präsentationslogik. Das Model kapselt die Businesslogik und deren Daten. View interagiert mittels Data-Binding und Events mit dem ViewModel Lose Kopplung
View Stellt die Daten / Informationen dar (Präsentation) Nimmt Benutzeraktionen entgegen. Kennt das ViewModel aber nicht das Model. Nicht für die Verarbeitung der Benutzerdaten zuständig. Definiert die Daten- und Befehls-Bindung zum ViewModel. Enthält im Idealfall keine Businesslogik.
Model Enthält Daten und Geschäftslogik. Greift - falls notwendig auf Backend zu. Unabhängig von Präsentation (View) und Steuerung (ViewModel). Zuständig für Daten und Methoden zur Datenmanipulation (CRUD Operationen).
ViewModel Stellt die Daten aus dem Model und die Befehle für die (eine) View bereit. Implementiert die Aktionslogik der View. Kennt das Model, jedoch nicht die View (nur via DataBinding). Abonniert das Model als Observer. Wird über Veränderungen im Model benachrichtigt.
Funktionalität
Beispiel: Angular Quelle: https://angular.io/guide/architecture
Beispiel: Angular (View und ViewModel) View: <h2>hero List</h2> <p><i>pick a hero from the list</i></p> <ul> <li *ngfor="let hero of heroes" (click)="selecthero(hero)"> {{hero.name}} </li> </ul> <hero-detail *ngif="selectedhero" [hero]="selectedhero"></herodetail> ViewModel: export class HeroListComponent implements OnInit { heroes: Hero[]; selectedhero: Hero; constructor(private service: HeroService) { } ngoninit() { this.heroes = this.service.getheroes(); } } selecthero(hero: Hero) { this.selectedhero = hero; }
Beispiel: Angular (Model) Model: @Injectable() export class HeroService { private heroes: Hero[] = []; constructor( private backend: BackendService, private logger: Logger) { } } getheroes() { this.backend.getall(hero).then( (heroes: Hero[]) => { this.logger.log(`fetched ${heroes.length} heroes.`); this.heroes.push(...heroes); // fill cache }); return this.heroes; }
Vorteile Einfachere View (fast kein GlueCode) Einfach austauschbar Strikte Trennung von Design und Logik Gute Testbarkeit Datengebunde View updatet sich automatisch Nachteile Grössere Komplexität Zweiseitiger Observer Grosser Rechenaufwand
Anwendung MVVM wird eingesetzt in XAML/WPF JavaFX HTML5 (HTML/JavaScript, z.b. Angular, Knockout,...)...
Multitier- and Layered Architecture
Umfeld Als Multitier Architecture wird ein Architekturmuster bezeichnet, bei der eine Applikation in mehrere eigenständige Schichten (Tiers) unterteilt wird, welche separate Laufzeitinstanzen sind. Das Layered Architecture Architekturmuster unterteilt die Anwendung ebenfalls in mehrere Schichten, welche jedoch typischerweise nicht alle eigenständig und separate Laufzeitinstanzen sind. Bei beiden erfolgt der Aufruf immer von der «höheren» zu der «tieferen» Schicht/Tier. Vorbild ist das OSI-Schichtenmodell (BetriebssystemTheorie).
Kategorie/Zweck der Layered Architecture Eine Schichten-Architektur ist ein häufig angewandtes Strukturierungsprinzip Durch eine Schichtenarchitektur wird die Komplexität der Abhängigkeiten innerhalb des Systems reduziert Klare Aufgabenteilung Geringe Kopplung Schichten verhindern Zyklen im Abhängigkeitsgraph Schichten werden (wegen ihrer wohldefinierten Aufgabe) gut verstanden.
Kategorie/Zweck der Multitier Architecture Die Unterteilung der Anwendung in mehrere Laufzeiteinheiten mit klar definierten Aufgaben ermöglicht eine bedarfsgerechte Skalierung der Anwendung. Jeder Tier hat seine klare Aufgabe: Klare Aufgabenteilung Geringe Kopplung 3-Tier Architektur: Aufteilung der Anwendung in: Client (z.b. JavaScript Client, läuft im Browser des Benutzers) Server (Businesslogik, läuft auf Server X oder in Cloud) Datenbank (Persistenz, läuft auf Server Y oder in Cloud) Eine Multitier Architektur bedingt den Einsatz von Layers, jedoch nicht umgekehrt.
Beispiel Layered Architecture Quelle: Software-Referenzarchitektur des EJPD
Beispiel Multitier Architecture Quelle: https://www.lucidchart.com/pages/uml/deployment-diagram
Vorteile Multitier- / Layered- Architecture Multitier-Architekturen sind gut skalierbar und weisen einen hohen Grad an Flexibilität auf. Einzelne Tiers resp. Layers sind einfach austauschbar. Bei Veränderung der Schnittstellen/Interfaces sind nur die beiden angrenzenden Tiers resp. Layers betroffen. Multitier-Architekturen kapseln MaschinenAbhängigkeiten und sind daher leicht portierbar. Multitier-Architekturen erlauben die örtliche Verteilung der Tiers (Hochverfügbarkeit, Katastrophenvorsorge)
Skalierbarkeit Scale-Up meist nur mit teurer Hardware möglich Multitier Architektur ist meist Voraussetzung für Scale-Out In der Cloud ist Scale-Out der Standard Cloud kann Scale-Out dynamisch anhand der Last vornehmen Multitier- und damit auch Layered Architecture ist heute Standard für Enterprise Anwendungen.
Nachteile Es ist oft schwierig Systeme sauber in Schichten zu strukturieren. Zwischen den Schichten sind zusätzliche Klassen/Interfaces oder sogar RemoteSchnittstellen nötig Zusätzlicher Overhead durch die Auftrennung in Schichten (Weiterleitung der Meldungen) Performanz-Probleme Eine (zu) grosse Anzahl Schichten verursacht eine unnötig komplexe Struktur
Verwendung Multitier- und Layered- Architekturen sind von Vorteil wenn grosse Skalierbarkeit und Flexibilität der Applikation erfordert ist. der Austausch einzelner Schichten einfach sein soll. Schnittstellen stabil bleiben (Standardschnittstellen). Komponenten und Hardware/Software-Plattformen austauschbar sein sollen. Man die Hardware/Software Plattformen einkauft Cloud. es möglich sein soll Komponenten mit komplexer Funktionalität weiter aufzuteilen. das System von mehreren Teams mit klaren Verantwortlichkeiten erstellt werden soll.
Praxisbeispiel: Netflix So hat sich die Anzahl der Streaming-Mitglieder seit 2008 verachtfacht und auch die Streaming-Nachfrage pro Nutzer ist stark gestiegen, was in acht Jahren zu einem 1.000-fachen Anstieg des Streaming-Aufkommens geführt hat. Strukturell sind wir von einer monolithischen App auf Hunderte von Mikrodiensten umgestiegen und haben unser Datenmodell mithilfe von NoSQL-Datenbanken denormiert. Quellen: https://openconnect.netflix.com, https://media.netflix.com/de/company-blog/completing-the-netflix-cloud-migration
Verweis auf andere Muster Verwandte (Strukturierungs-) Muster sind Microservices: Eine Anwendung besteht aus mehreren Services, welche eine genau abgegrenzte Funktionalität der Anwendung zur Verfügung stellen. Sie basieren auf der Multitierund auch auf der Layered- Architecture. Hexagonal Architecture: Beispiel für Layered Architecture. Quelle: http://alistair.cockburn.us/hexagonal+architecture