Im Moment liest man überall vom ASP.NET Model View Controller (MVC) Framework. Das MVC Framework unterscheidet zwischen einem Model, einer View und einem Controller, und führt so zu einer klaren Aufgabentrennung und leichter testbarem Code.
Um testbare ASP.NET Web Seiten zu schreiben, bei der die Darstellung (View) sauber von der Logik und vom Modell getrennt ist, muss man jedoch nicht erst auf das MVC Framework warten. Auch mit ASP.NET Web Forms ist es möglich, gut strukturierte und testbare Anwendungen zu entwickeln.
Ein Ansatz dafür ist das Model-View-Presenter (MVP) Pattern. Auf den ersten Blick ist das MVP Pattern dem MVC Pattern sehr ähnlich. Beide Ansätze verfolgen im Prinzip die gleichen Ziele, erreichen diese nur auf einem anderen Weg. Eine genaue Beschreibung der Unterschiede gibt es z.B. unter
http://ameleta.spaces.live.com/blog/cns!5F6316345A821420!163.entry
http://stackoverflow.com/questions/2056/what-are-mvp-and-mvc-and-what-is-the-difference#101561
Das Pattern das ich verwende ist eine Variante des MVP Patterns, und nennt sich “Supervising Controller”. Dieses Pattern wird von Fowler sehr ausführlich beschrieben.
Meine Implementierung des MVP Patterns basiert auf einer Implementierung von David Hayden: http://www.pnpguidance.net/Post/UnityIoCDependencyInjectionASPNETModelViewPresenter.aspx
David verwendet das MVP Pattern zusammen mit Microsoft Unity als Dependency Injection Container. Über das Thema Dependeny Injection werde ich später vielleicht in einem eigenen Beitrag schreiben, bis dahin soll es ausreichen zu wissen, dass sich Unity darum kümmert, dass Model, View und Presenter richtig miteinander “verdrahtet” werden.
David hat Basisklassen für View und Presenter geschrieben. Die View ist bei ihm eine von System.Web.Page abgeleitete Klasse. Die View hat zwei Typparameter, TView und TPresenter. Als TView übergeben wir ein Interface, das die Methoden enthält, über die der Presenter Daten in der View darstellen kann. TPresenter ist der zur View passende Presenter. Die View erhält eine Referenz zu ihrem Presenter, und benachrichtigt diesen dann über verschiedene Ereignisse (Seite geladen, Button geklickt usw.).
Ich habe mit Davids Code angefangen und bin dann mehrfach an Stellen gekommen, wo ich seinen Code erweitern musste. So soll z.B. eine einzelne Seite oft nicht nur eine View, sondern gleich mehrere unterschiedliche Views in Form von Steuerelementen darstellen können. Dafür habe ich eine BaseControl-Klasse geschrieben, die von UserControl ableitet und so MVP basierte UserControls ermöglicht. Auch für MasterPages möchte ich das MVP Pattern einsetzen können, und habe dafür eine BaseMasterPage geschrieben.
An einigen Stellen musste ich auf ASP.NET-spezifische Klassen wie SessionState und Cache zugreifen. Um diese besser testen zu können und in meinen Tests unabhängig von ASP.NET zu bleiben habe ich mir für diese Fälle die Interfaces ICacheProvider bzw. IStateProvider geschrieben, die von BasePage/BaseControl/BaseMasterPage implementiert werden, und somit einen Zugriff auf SessionState und Cache ermöglichen, ohne dass ich dafür in meinen Tests ASP.NET Klassen verwenden müsste.
Als letzte Klasse gibt es dann schließlich noch die BaseApplication, die sich genau wie die HttpApplication-Klasse in Davids Beispiel um die Initialisierung des Unity-Containers kümmert.
Zusammengenommen ergibt sich damit folgendes bild:
Da ich diese Klassen so in mehreren Projekten verwenden kann (und auch bereits verwendet habe) habe ich das alles noch in ein eigenes Projekt ausgelagert.
Soweit die Theorie. In Teil zwei zeige ich dann an Beispielen aus meinem Quellcode, wie ich das MVP Pattern angewendet habe.