MVC – ein Architekturmuster

1. MVC – ein Architekturmuster ETIS SS04

2. Gliederung • Motivation • Pattern • Pattern am Beispiel MVC • Zusammenfassung MVC

3. Motivation (I) • Ist es schwierig für euch in eurem JSPs Übersicht behalten (jetzt /später)? • Wie schwer wäre es für einen anderen (ohne Java-Kenntnisse)? • Was passiert bei wachsender Komplexität? • Wie würdet ihr neue JSP Seiten erstellen, die auf den selben Daten arbeiten? • Was wäre zu tun, um nicht-grafische oder Swing-Oberflächen zu erstellen? • Wie wirken sich DB-Änderungen aus? MVC

4. Motivation (II) • Wie sind Probleme (schlechte Lesbarkeit, Wartbarkeit, Wiederverwendbarkeit) lösbar? • Geeigneter Entwurf • Sollte beim Entwurf komplett neu angefangen werden? • Nein, Zurückgreifen auf erfolgreiche Lösungen sinnvoll • Erfolgreiche Lösungen können in Form von Pattern festgehalten werden • Einfache, leichter verständliche Entwürfe • Schnelle, kostengünstige Software-Entwicklung MVC

5. Pattern • Ursprünge Ch. Alexander in Architektur bzw. Gamma u.a. in Softwaregemeinde • Beschreibung bestimmten im Entwurfskontext häufig auftretenden Problems • Erläuterung des Kerns der Lösung dieses Problems • Somit: Lösung beliebig oft ausführbar, aber i.d.R. nicht gleich • Vermitteln bewährte Entwürfe • Vermeiden „das Rad neu zu erfinden“ MVC

6. Pattern • Unterliegen ständigen Verbesserungen • Können auf unterschiedlichen Abstraktionsebenen liegen • Architekturmuster: Softwaresysteme durch Subsysteme strukturiert • Entwurfsmuster: Verfeinerung Subsysteme oder Beziehungen zwischen ihnen • Idiome: Aspekte des Entwurfs in bestimmter Programmiersprache • Sind kombinierbar • in strukturiertem Format beschrieben und in sog. Katalogen abgelegt MVC

7. 50 % 25 % 25 % Pattern am Beispiel MVC [Buschmann] • Name: MVC • Auch bekannt als: - • Beispiel: Rot Schwarz Grün MVC

8. Pattern am Beispiel MVC [Buschmann] • Kontext: • Interaktive Anwendungen • Problem: • Häufige Änderungsanforderungen für Bedienschnittstellen • Erweiterung der Anwendung • Portierung des Systems • unterschiedliche Anforderungen der Anwender • Verwobene Bedienoberfläche und funktionaler Kern erschweren Entwicklung flexibler Systeme • Jede Änderung trifft mehrere Module MVC

9. Pattern am Beispiel MVC [Buschmann] • Kräfte: • Unterschiedliche Darstellung selber Information • Darstellung und Verhalten muss Datenänderung widerspiegeln • Änderungen an der Bedienoberfläche sollten leicht sein • Unterstützung verschiedener Standards oder Portierung sollten Code der Anwendung nicht beeinflussen MVC

10. Pattern am Beispiel MVC [Buschmann] • Lösung: Unterteilung der Anwendung in drei Bereiche • Modell: enthält Daten und Kernfunktionalität • View: zeigt Information, erhält Daten vom Modell, sendet Nutzerverhalten zum Controller • push: Registrierung beim Modell  Benachrichtigung von Modell • pull: View fragt Modell, für aktuelle Daten • Controller: empfängt Eingaben, bildet sie auf Modelländerungen ab, wählt View für Darstellung • Trennung ermöglicht mehrere Ansichten auf einem Modell • Ändert ein Anwender Modell, so ändern sich auch andere Sichten MVC

11. View Änderungen Status erfragen Benutzeraktionen View-Auswahl Model Controller Status ändern Pattern am Beispiel MVC [Buschmann] • Struktur: MVC

12. Pattern am Beispiel MVC [Buschmann] • Implementierung / Musterlösung • Übung • Varianten • Model-View-Presenter (MVP) • Document-View • Anwendungen: • Smalltalk • JFC (Swing) • MVC – Frameworks (Struts, Tapestry, Cocoon) MVC

13. Pattern am Beispiel MVC [Buschmann] • Auswirkungen • Mehrere Ansichten auf selben Modell möglich • Synchronisierte Ansichten • Modell durch Portierung der Anwendung nicht beeinflusst • Bessere Lesbarkeit, Wartbarkeit, Wiederverwendbarkeit • Große Komplexität → längere Planung / mehr Implementierungsaufwand • Controller und Ansicht sind eng gekoppelt • Verweise • PAC: trennt Abstraktionskomponente (Model) von Präsentationskomponenete (View und Controller) MVC

14. Zusammenfassung • Bisher in Übung alles in eine JSP geschrieben (Modell1) • Probleme bzgl. Wiederverwendbarkeit, Wartbarkeit • Verbesserung durch Auslagerung von Geschäfts- und Datenzugriffslogik in Bean • Weitere Verbesserung durch Einführung Controller (Modell 2) • Schicht für Authentifizierung und Autorisierung • Vermittlung von Anfragen an entsprechende JSP • Bereitstellung von Ressourcen z.B. DB-Verbindung MVC

15. Zusammenfassung • Varianten Modell2: • Vermittler-Servlet an JSP • Vermittler-Servlet an JSP mit Templates • Vermittler-Servlet an Worker-Bean • Je besser Strukturierung: • um so höher Wiederverwendbarkeit, Wartbarkeit • aber größere Planungsphase und höherer Implementierungsaufwand • Für große Anwendungen lohnenswert MVC

16. Literatur • Gamma, E., Helm, R., Jonson, R., Vlissides, J., Entwurfsmuster, Addison Wesley, Bonn, 1996 • Buschmann, F., Meunier, R., Pattern orientierte Software Architektur, Addison Wesley, Bonn, 1998 • http://java.sun.com/blueprints/patterns/MVC-detailed.html • Turau, V., Saleck, K., Lenz, C., Web basierte Anwendungen entwickeln mit JSP2, dpunkt.verlag, Heidelberg, 2004 • Alur, D., Core J2EE Patterns, Markt + Technik Verlag, München, 2002 MVC