View
6
Download
0
Category
Preview:
Citation preview
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
Rich Client, GUI Applikation Multitier- und Layer- Architektur
Web Bereich, JavaEE , .Net, Client-Server Service-Oriented (Prozess-Orientiert), Peer-to-Peer, ...
Verteilte Systeme
Domain Driven Design, Hexagonale Architektur
– Innerer Aufbau von Softwarekomponenten Reflection, Inverstion of Control, Dependency Injection,...
Adaptive (Komponenten) Systeme, Entkoppelung
Model View Controller
Modell-Präsentation-Steuerung
Problem/Umfeld
ASD: 95CJA: 64FBU: 109JPQ: 152SGD: 204
ASD: 95CJA: 64FBU: 109JPQ: 152SGD: 204
95 15%
64 10%
109 18%
152 24%
204 33%
ASD
CJA
FBU
JPQ
SGD
View 1: Pie Chart View 2: Bar Chart View 3: Spread Sheet
Verschiedene Nutzer oder Sichten der gleichen Daten
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
BenutzerBenutzer
Eingabe
Ausgabe
ControllerController
ViewModelModel
Model Daten und ihre VerarbeitungView Präsentation der DatenController 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 im MVC üblicherweise benutzt
Model View Presenter 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 Benutzer-Eingaben?
→ 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 LogikVereinfachung der Schnittstelle durch Data-
Binding
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 zumViewModel.
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 zurDatenmanipulation (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"></hero-detail>
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 (Betriebssystem-Theorie).
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 Maschinen-Abhä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 Remote-Schnittstellen 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 Multitier- und auch auf der Layered- Architecture.
Hexagonal Architecture: Beispiel für Layered Architecture.
Quelle: http://alistair.cockburn.us/Hexagonal+architecture
Recommended