Muster sind seit einigen Jahren eines der beliebtesten Forschungsthemen innerhalb der Software- Entwicklung. Das Interesse entstand vor allem vor dem Hintergrund, dass lange Zeit zwar gute Entwurfsmethoden und Sprachen wie z.B. die Unified Modeling Language UML vorhanden waren, es jedoch an dokumentierten, praxistauglichen Entwürfen für Software-Systeme fehlte und somit bei neuen Problemen oft gleiche Lernprozesse wiederholt werden mussten. Muster dagegen halten nicht nur gewisse Methoden fest, sie beinhalten zusätzlich Erfahrungen der Software-Entwickler in einer Form, die ihre Wiederverwendung möglich macht. Auf diese Weise ist es möglich, von den Erfahrungen langjähriger Entwickler zu profitieren, ohne selbst Experte zu sein.
Darüber hinaus stellt die Verwendung eines in der Praxis erprobten Musters sicher, dass die entwickelte Software bestimmten Anforderungen genügt, die an das Muster gestellt wurden. So sind in den letzten Jahren diverse Muster entwickelt bzw. gefunden worden, deren Anwendung Anpassungsfähigkeit und Flexibilität eines Softwaresystems gewährleistet. Die in dieser Arbeit behandelten Web Presentation Patterns stellen solche praxiserprobten Muster dar, die konkret auf das Anwendungsgebiet dynamischer Web-Applikationen bezogen wurden. Ihre Anwendungsbereiche reichen von der grundlegenden Trennung zwischen Anwendungslogik und Darstellung über die flexible Gestaltung von Web-Anwendungen bis hin zu unterschiedlichen Verfahren zum Cachen oft aufgerufener Seiten. Viele dieser Muster lassen sich mit einigen Anpassungen in der .NET-Umgebung besonders effizient umsetzen, indem von speziellen Klassen oder Mechanismen des .NET-Frameworks Gebrauch gemacht wird.
Inhalt
1 Einleitung
2 Muster in der Software-Entwicklung
3 Web Presentation Patterns
3.1 Model View Controller
3.2 Page Controller
3.3 Front Controller
3.4 Intercepting Filter
3.5 Page Cache
3.6 Observer
4 Zusammenfassung
Abbildungsverzeichnis
Literaturverzeichnis
1 Einleitung
Muster sind seit einigen Jahren eines der beliebtesten Forschungsthemen innerhalb der Software-Entwicklung. Das Interesse entstand vor allem vor dem Hintergrund, dass lange Zeit zwar gute Entwurfsmethoden und Sprachen wie z.B. die Unified Modeling Language UML vorhanden waren, es jedoch an dokumentierten, praxistauglichen Entwürfen für Software-Systeme fehlte und somit bei neuen Problemen oft gleiche Lernprozesse wiederholt werden mussten (vgl. [Fow99, S. 5f.]). Muster dagegen halten nicht nur gewisse Methoden fest, sie beinhalten zusätzlich Erfahrungen der Software-Entwickler in einer Form, die ihre Wiederverwendung möglich macht. Auf diese Weise ist es möglich, von den Erfahrungen langjähriger Entwickler zu profitieren, ohne selbst Experte zu sein (vgl. [GHJV04, S. 1ff.]).
Darüber hinaus stellt die Verwendung eines in der Praxis erprobten Musters sicher, dass die entwickelte Software bestimmten Anforderungen genügt, die an das Muster gestellt wurden. So sind in den letzten Jahren diverse Muster entwickelt bzw. gefunden worden, deren Anwendung Anpassungsfähigkeit und Flexibilität eines Softwaresystems gewährleistet.
Die in dieser Arbeit behandelten Web Presentation Patterns stellen solche praxiserprobten Muster dar, die konkret auf das Anwendungsgebiet dynamischer Web-Applikationen bezogen wurden. Ihre Anwendungsbereiche reichen von der grundlegenden Trennung zwischen Anwendungslogik und Darstellung über die flexible Gestaltung von Web-Anwendungen bis hin zu unterschiedlichen Verfahren zum Cachen oft aufgerufener Seiten. Viele dieser Muster lassen sich mit einigen Anpassungen in der .NET-Umgebung besonders effizient umsetzen, indem von speziellen Klassen oder Mechanismen des .NET-Frameworks Gebrauch gemacht wird.
2 Muster in der Software-Entwicklung
Muster beschreiben Lösungsansätze für verbreitete und immer wieder auftretende Probleme in der Software-Entwicklung und ermöglichen so die Nutzung des in den Mustern beschriebenen Wissens erfahrener Software-Ingenieure durch weniger erfahrene Entwickler. Es hat sich gezeigt, dass solche wiederkehrenden Probleme bei der Entwicklung von Software nicht selten sind, daher hat sich in den letzen Jahren der Trend entwickelt, Muster zum Lösen diverser Probleme zu sammeln und zu dokumentieren (z.B. [BMR+98], [Fow03] und [GHJV04]).
Diese Art von Mustern als "Idee, die in einem praktischen Kontext hilfreich war und dies auch in anderen sein könnte" (aus [Fow99, S. 9]) wird allerdings nicht nur in der Software-Entwicklung benötigt, der Begriff trat vielmehr erstmals in diesem Zusammenhang in der Architektur auf (vgl. [Ale79]). Auch hier ergeben sich wiederkehrende Problemstellungen, die mit leichten Anpassungen immer auf die gleiche Art und Weise gelöst werden können. Im Folgenden werden einige Aspekte von Mustern in der Software-Entwicklung kurz beschrieben.
Eigenschaften. Ein Muster dokumentiert eine erprobte Lösung für ein in speziellen Entwurfssituationen häufig auftretendes Problem und abstrahiert dabei von Details, die für die Lösung irrelevant sind. Daraus ergibt sich, dass die allgemeine Lösung immer noch für die konkrete Anwendungssituation angepasst werden muss, andere Autoren sprechen daher von einem Lösungsansatz.
Muster erweitern das Vokabular von Software-Entwicklern und machen so im Idealfall umständliche Erklärungen einer Lösung überflüssig. Hat sich ein Muster unter einem bestimmten Namen etabliert, so kann seine Anwendung als Grundwissen eines Software-Entwicklers vorausgesetzt werden.
Dokumentation. Für die Dokumentation von Mustern hat sich in den letzten Jahren ein Standard durchgesetzt, der von den führenden Autoren eingehalten und teilweise erweitert wird. Demnach setzt sich ein Muster aus den drei Teilen Kontext, Problem und Lösung zusammen. Diese Teile stehen in einer Beziehung dergestalt, dass eine Lösung für ein Problem beschrieben wird, das in einem bestimmten Kontext auftritt. Unter Kontext versteht man die Situation, in der das Problem auftritt bzw. auftreten kann. Das Problem wird oft, z.B. im Rahmen der Microsoft Web Presentation Patterns (vgl. [MSDN04]), durch eine Liste von forces bzw. Kräften beschrieben. Unter Kräften versteht man in diesem Fall sämtliche Aspekte, die im angegebenen Kontext wirken und bei der Lösung zu berücksichtigen sind. [BMR+98, S. 9] teilt diese Kräfte wiederum in die Untergruppen Anforderungen (requirements), Randbedingungen (constraints) und wünschenswerte Eigenschaften (desirable properties) auf. Die Lösung gleicht schließlich die beteiligten Kräfte aus, so dass das Problem gelöst wird. Abdecken muss die Lösung sowohl die statische Struktur der beteiligten Komponenten, die durch eine bestimmte Architektur definiert wird, als auch das Verhalten zur Laufzeit und damit die Interaktion der beteiligten Komponenten.
Beziehungen. Bei der Beschreibung von Mustern darf nicht außer Acht gelassen werden, dass die meisten Muster keineswegs unabhängig voneinander zu betrachten sind, sondern vielmehr Interdependenzen vorliegen. So kann z.B. die Anwendung eines Musters zu einem neuen Problem führen, das durch ein weiteres Muster lösbar ist. Vielfach ist auch ein Muster eine Variante eines anderen Musters, außerdem können Muster für bestimmte Zwecke kombiniert werden[1]. Diese Abhängigkeiten haben zu einem Wandel in der Literatur über Muster geführt. Wurden zunächst Muster meist in so genannten Musterkatalogen aufgezählt (z.B. [GHJV95]), so entwickelt sich der Trend mehr und mehr dahin, Mustersysteme vorzustellen, die die Beziehungen zwischen den Mustern stärker in den Blickpunkt rücken (z.B. [BMR+98]).
Verwendung. Die Verwendung eines Musters ist nicht trivial, die Probleme beginnen bereits mit dem Auswählen des passenden Musters. Dazu ist es oft notwendig, den Musterkatalog bzw. das Mustersystem nach Problemen zu durchsuchen, die eine gewisse Ähnlichkeit mit dem eigenen Problem aufweisen. Ob ein Muster geeignet ist, um ein gegebenes Problem zu lösen, lässt sich oft nur durch Ausprobieren klären (vgl. [Fow99, S. 15]). Dabei sollte allerdings nicht unter allen Umständen versucht werden, ein Problem in ein bestimmtes Muster zu zwängen, nicht jedes Muster ist für jedes Problem geeignet. [GHJV04, S. 42] weist weiterhin darauf hin, dass Muster die vielfach angestrebten Eigenschaften Flexibilität und Variabilität oft auf Kosten der Einfachheit eines Software-Systems erreichen. Ein Muster sollte daher nur dann Anwendung finden, wenn seine positiven Eigenschaften wirklich benötigt werden.
3 Web Presentation Patterns
In [MSDN04] stellt Microsoft sechs verschiedene Muster vor, die vor allem im Kontext dynamischer Web-Anwendungen hilfreich sind. Einige der Muster sind allerdings auch für Desktop-Applikationen geeignet und werden in der Software-Entwicklung schon seit Jahren erfolgreich eingesetzt.
Die Beschreibungen der Muster im Folgenden halten sich eng an die in Kapitel 2 beschriebene Gliederung und diskutieren für jedes Muster das vorliegende Problem sowie den Lösungsansatz, den das Muster vorschlägt. Darüber hinaus beschäftigt sich jeweils ein Abschnitt mit den Implikationen des jeweiligen Musters und mit den Möglichkeiten einer konkreten Implementierung[2] unter Ausnutzung der umfangreichen Klassenbibliothek von .NET.
3.1 Model View Controller
Problem. Bei der Entwicklung vieler Informationssysteme hat sich gezeigt, dass Benutzeroberflächen deutlich öfter geändert oder an neue Umgebungen angepasst werden müssen als die zugehörige Fachlogik. Dabei müssen teilweise Anpassungen für Darstellungen auf anderen Geräten[3] vorgenommen werden. Werden Darstellung und Fachlogik im selben Objekt verwaltet, muss jedes Mal, wenn die Benutzeroberfläche geändert wird, das Objekt geändert werden, das die Fachlogik enthält. Dies kann leicht zu Fehlern führen, und nach jeder Änderung in der Präsentation der Daten muss die komplette Fachlogik erneut getestet werden.
Außerdem werden oft für dieselbe Fachlogik mehrere unterschiedliche Darstellungen benötigt. Um dann eine Code-Duplizierung zu vermeiden, sollte die Fachlogik für die unterschiedlichen Darstellungen selbstverständlich nur einmal implementiert werden um Redundanz zu vermeiden und um zu verhindern, dass eine logische Änderung an mehreren Stellen im Quelltext nachvollzogen werden muss.
Für die Forderung einer Trennung zwischen Fachlogik und Präsentation bei interaktiven Systemen (z.B. [Fow03, S. 369]) spricht weiterhin die Tatsache, dass Software-Entwickler oftmals auf eines der beiden Gebiete spezialisiert sind. Es sollte also für ein Entwicklerteam möglich sein, die Fachlogik zu ändern, ohne in den Quelltexten einer anderen Gruppe Anpassungen vornehmen zu müssen.
Lösung. Model View Controller beschreibt allgemein, aus welchen Komponenten sich interaktive Systeme zusammensetzen sollten und wie diese miteinander kommunizieren. Die Anwendung dieses Musters erfüllt die vorstehend genannten Anforderungen und unterteilt eine Applikation in drei Komponenten (vgl. [Wik04] und Abbildung 1):
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Klassendiagramm für Model View Controller, in Anlehnung an [Fow03, S. 367]
Model. Das Datenmodell verwaltet die persistenten Daten der Anwendung sowie die notwendige Fachlogik, um Änderungen an den Daten vorzunehmen. In der Praxis hat das Model daher meist Zugriff auf die im System verwendete Datenhaltung (Datenbanken etc.).
View. Views dienen der Datenrepräsentation und enthalten keine Fachlogik. Sie kennen das Model, für ein Model kann es beliebig viele Views geben.
Controller. Der Controller nimmt Client-Anfragen entgegen und extrahiert die enthaltenen Informationen. Aufgrund dieser Informationen wird die Fachlogik des zugehörigen Models aktiviert. Nach Abarbeitung der Anfrage gibt das Model die Steuerung an den Controller zurück, der daraufhin den entsprechenden View mit den relevanten Informationen aktiviert.[4] Zu einem Model kann eine beliebige Anzahl von Controllern gehören.
Zu betonen ist, dass das Model weder die zugeordneten Controller noch die zugeordneten Views kennt, es ist also von diesen völlig unabhängig. Neue Views oder Controller können zu einem Model hinzugefügt werden, ohne das Model anpassen zu müssen.
Implikationen. [Fow03] beschreibt auf den Seiten 368f. die beiden Trennlinien, die vom Model View Controller impliziert werden. Die Trennung zwischen Präsentation und Modell ist eines der Grundkonzepte professioneller Software-Entwicklung und ermöglicht die vielzitierte separation of concerns sowie die Erstellung vieler Präsentationen für dieselben Daten ohne redundanten Quelltext. Die andere Trennlinie verläuft zwischen View und Controller. Das klassische Beispiel für eine derartige Trennung ist die Präsentation einer editierbaren und einer nicht editierbaren Version derselben Daten, hier besteht aufgrund der Separierung von View und Controller die Möglichkeit, einen View und zwei Controller, einen für die editierbare und einen für die nicht editierbare Variante, zu verwenden. In der Praxis findet man jedoch meist einen Controller pro View vor, und die Trennung wird oft gar nicht vollzogen[5].
In Web-Anwendungen ist die Trennung zwischen View und Controller jedoch vorhanden: Der View wird durch HTML-Code im Browser auf der Client-Seite realisiert, der Controller durch die serverseitige Komponente, die die Benutzeranfragen verarbeitet (vgl. [MSDN04]).
Implementierungen in .NET. In ASP.NET kann eine Seite, die anfragespezifische Daten aus einer Datenbank lädt und dem Benutzer anzeigt, auf unterschiedliche Arten implementiert werden. Der kürzeste Weg ist, den notwendigen Quelltext für die Datenbankanfrage sowie für die Verarbeitung der Benutzereingabe als Skript in die .aspx-Datei einzufügen. Diese Lösung enthält jedoch sämtliche Nachteile, die vorstehend als Gründe für die Anwendung von Model View Controller aufgeführt wurden, da alle drei Rollen in derselben Datei implementiert werden.
Die Trennung zwischen Fachlogik und Präsentation wird in ASP.NET durch die Code Behind Technologie erleichtert. Code Behind bietet eine Möglichkeit, Web-Applikationen zu gliedern und objektorientiert zu entwickeln, indem eine strikte Trennung zwischen Programmteil und HTML ermöglicht wird.[6] Die ASP.NET-Seite beginnt dann mit einer @Page-Direktive, die auf die Klasse verweist, die den Code Behind Quelltext enthält, der restliche Teil bleibt bis auf die Tatsache, dass der komplette Skript-Teil fehlt, identisch. Die Code Behind Klasse wird von System.Web.UI.Page abgeleitet und enthält den Quelltext, der sich in der Ursprungsversion im Skriptteil der .aspx-Seite befand. Zu beachten ist dabei, dass die Variablen in der Code Behind Klasse, die die HTML-Steuer- und Ausgabeelemente repräsentieren, den gleichen Namen besitzen müssen wie die entsprechenden Gegenstücke in der ASP.NET-Seite. Die Code Behind Klasse muss außerdem die Methode InitializeComponent() enthalten, die die von der .NET-Umgebung ausgelösten Ereignisse mit den entsprechenden Funktionsaufrufen verbindet und beispielsweise folgende Zeile enthalten könnte (nach [MSDN04]):
this.submit.Click +=
new System.EventHandler(this.SubmitBtn_Click);
Diese Zeile legt fest, dass ein Klicken des Submit-Buttons die Ausführung der SubmitBtn_Click-Methode hervorruft, die in der Code Behind Klasse implementiert ist.[7]
Der letzte notwendige Schritt zur kompletten Anwendung des Model View Controller besteht in der Trennung von Model und Controller. Dieser Schritt ist mehr oder weniger trivial und teilt den Quelltext der Code Behind Klasse lediglich in eine Klasse mit ASP.NET-abhängigem und eine Klasse mit ASP.NET-unabhängigem Quelltext auf. Der ASP.NET-abhängige Teil realisiert die Rolle des Controllers und verarbeitet die Benutzeraktionen (z.B. das Klicken des Submit-Buttons), indem die entsprechende Methode der anderen Klasse aufgerufen wird. Die ASP.NET-unabhängige Klasse enthält allgemeine Methoden zum Auslesen und zur Änderung der Daten und stellt vielfach lediglich die Schnittstelle zur Datenbank dar. Im Umkehrschluss bedeutet dies, dass die Controller -Klasse von der konkreten Datenhaltung unabhängig ist, durch die vorgestellte Implementierung werden also alle geforderten Trennlinien eingehalten.
3.2 Page Controller
Problem. In Web-Applikationen findet bei Anwendung des Model View Controller eine Trennung zwischen View und Controller statt, da die Präsentation im clientseitigen Browser und die Steuerung auf Server-Seite realisiert wird. Dies ermöglicht unter anderem, dass durch mehrere unterschiedliche Aktionen der gleiche Code zum Erstellen der entsprechenden Präsentation verwendet werden kann, um Code Duplikation zu vermeiden. Wird jedoch für jede neue Seite ein neuer Controller verwendet, so findet trotzdem meist Code Duplikation statt, da viele Aktionen bei jeder Interaktion zwischen Client und Server in gleicher Weise ausgeführt werden müssen, [MSDN04] nennt hier unter anderem die Beispiele Sitzungsverwaltung und Auslesen der Parameter.
[...]
[1] Für letzteres wird in Abschnitt 3.6 ein Beispiel gegeben.
[2] Ausführliche Code-Beispiele zu allen sechs Web Presentation Patterns finden sich in [MSDN04], diese werden hier aus Platzgründen nicht komplett wiedergegeben.
[3] [MSDN04] nennt hier als Beispiele PDAs und internet-fähige Handys.
[4] Der Terminus Controller hat oft zu Irritationen geführt. Er enthält nicht die gesamte Fachlogik, sondern fungiert lediglich als „Input-Controller“ (nach [Fow03, S. 72]).
[5] Genau genommen handelt es sich dann um das Document View Muster, das [BMR+98, S. 141] als Variante des Model View Controller vorstellt.
[6] Die Code Behind Technologie wird z.B. in [Lor02, S. 701ff.] detailliert beschrieben.
[7] Das hier verwendete Delegatmodell von .NET wird in Abschnitt 3.6 detaillierter beschrieben.
-
-
-
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X. -
-
¡Carge sus propios textos! Gane dinero y un iPhone X.