Microsoft Patterns: Web Presentation Patterns

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 wa­ren, es jedoch an dokumentierten, praxistauglichen Entwürfen für Software-Systeme fehlte und somit bei neuen Prob­lemen oft gleiche Lernprozesse wiederholt werden mussten (vgl. [Fow99, S. 5f.]). Muster dage­gen halten nicht nur gewisse Methoden fest, sie beinhalten zusätzlich Erfahrun­gen der Software-Entwickler in einer Form, die ihre Wiederverwendung möglich macht. Auf diese Weise ist es möglich, von den Erfah­rungen 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 ent­wickelte 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 An­passungsfä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 An­passungen 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 Prob­leme 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 Anpassun­gen 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 Entwurfs­situationen häu­fig 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 An­wendungssituation angepasst werden muss, andere Auto­ren sprechen daher von einem Lösungs­ansatz.

Muster erweitern das Vokabular von Software-Entwicklern und machen so im Idealfall um­ständ­liche 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 Stan­dard 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 Micro­soft Web Presentation Patterns (vgl. [MSDN04]), durch eine Liste von forces bzw. Kräften beschrie­ben. Unter Kräften versteht man in diesem Fall sämtliche Aspekte, die im angegebenen Kontext wir­ken 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ün­schens­werte Eigenschaften (desirable properties) auf. Die Lösung gleicht schließlich die betei­ligten Kräfte aus, so dass das Problem gelöst wird. Abdecken muss die Lösung sowohl die stati­sche 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 Prob­lem 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 zu­nä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 eige­nen 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 Einfach­heit 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 dynami­scher Web-Anwendungen hilfreich sind. Einige der Muster sind allerdings auch für Desktop-Ap­plikationen geeignet und werden in der Software-Entwicklung schon seit Jahren erfolgreich einge­setzt.

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 Impli­kationen des jeweiligen Musters und mit den Möglichkeiten einer konkreten Imp­lementierung^[2] unter Ausnutzung der umfangreichen Klassenbibliothek von .NET.

3.1 Model View Controller

Problem. Bei der Entwicklung vieler Informationssysteme hat sich gezeigt, dass Benutzer­ober­flächen deutlich öfter geändert oder an neue Umgebungen angepasst werden müssen als die zu­gehö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äsenta­tion 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 unter­schiedlichen Darstellungen selbstverständlich nur einmal implementiert werden um Redundanz zu vermeiden und um zu ver­hindern, dass eine logische Änderung an mehreren Stellen im Quelltext nachvoll­zogen werden muss.

Für die Forderung einer Trennung zwischen Fachlogik und Präsentation bei interaktiven Syste­men (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 vorneh­men zu müssen.

Lösung. Model View Controller beschreibt allgemein, aus welchen Komponenten sich interak­tive Systeme zusammensetzen sollten und wie diese miteinander kommunizieren. Die Anwen­dung dieses Musters erfüllt die vorstehend genannten Anforderungen und unterteilt eine Appli­kation in drei Kom­ponenten (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 enthalte­nen Informationen. Aufgrund dieser Informationen wird die Fachlogik des zugehörigen Models aktiviert. Nach Abarbeitung der Anfrage gibt das Model die Steue­rung 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ög­licht die vielzitierte separation of concerns sowie die Erstellung vieler Präsentationen für diesel­ben 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 Ver­sion derselben Daten, hier besteht aufgrund der Separierung von View und Controller die Mög­lichkeit, einen View und zwei Controller, einen für die editierbare und einen für die nicht editier­bare 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 serversei­tige 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 wer­den. 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 wer­den.

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 Tatsa­che, dass der komplette Skript-Teil fehlt, identisch. Die Code Behind Klasse wird von Sys­tem.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 besit­zen 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-Um­gebung ausgelösten Ereignisse mit den entsprechenden Funktionsaufrufen verbindet und bei­spielsweise 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-But­tons), indem die entsprechende Methode der anderen Klasse aufgerufen wird. Die ASP.NET-un­abhängige Klasse enthält allgemeine Metho­den 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 Implemen­tierung werden also alle geforderten Trennlinien eingehalten.

3.2 Page Controller

Problem. In Web-Applikationen findet bei Anwendung des Model View Controller eine Tren­nung 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 ver­wendet 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 an­derem die Beispiele Sitzungsverwaltung und Auslesen der Para­meter.

[...]

^[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.