Nach der Installation des ASP.NET MVC Preview 4 Release musste ich noch die Code Templates für Visual Studio nachträglich installieren. Diese findet man hier.

Wenn man jetzt ein ASP.MVC Projekt anlegt bekommt man folgende Struktur im Projekt:

Genau wie andere MVC Frameworks muss man hier auf die richtige Namensgebung der Klassen und Template Dateien achten.

Die Controller Klassen müssen immer mit Controller enden (Controller/TasksController.vb) und die View Templates müssen in dem Ordner liegen wie der Controller heißt und den Namen der Methode haben (/Views/Tasks/Create.aspx).

Gut gelöst ist das URL Mapping. Um eine Action aufzurufen, gibt man in der Url den Namen des Controllers an und dessen Methode.

Beispiel:

/Tasks/Create/

Diese Url ruft die Methode Create der Klasse TaskController auf.

Schön gelöst ist die Verwendung von Parametern in Controllern. Man kann in der Signatur einer Controller Methode angeben, welche Parameter angegeben werden können und auch dessen Typ festlegen.

Function Complete(ByVal id As Integer) As ActionResult

Die Übergabe der Daten an die View erfolgt genau so einfach indem man die Werte als Parameter dem View übergibt.

Return View(tasks.ToList())

Diese Werte kann man in der View aspx Seite dann aus dem Property ViewData auslesen.

Fazit

Es handelt sich hier um ein sehr einfach zu bedienendes Framework das sehr schlank daher kommt. Die Einarbeitung geht schnell. In Verbindung mit Linq kann man damit sehr schnell übersichtliche Applikationen schreiben. Das Framework kommt völlig ohne die ASP Tags aus. Das macht es auch für unerfahrene ASP Entwickler einfach.

Sehr gute Screencasts findet man hier: http://www.asp.net/learn/mvc-videos/

Beispielsweise kann es sein das nach einen Login verschiedene Dinge geprüft werden müssen. Zusätzlich sollen vielleicht noch Aktionen geloggt werden.

Wenn man jedesmal den Code für den Login erweitern würde, dann hätte man innerhalb kürzester Zeit eine riesige Klasse mit schwer wartbaren Code.

Bei dem Observer Pattern gibt eine Anwendung nur bekannt das ein bestimmtes Ereignis (Event) stattgefunden hat. Andere Programmteile können sich von außen an den EventDispatcher anmelden und werden dann von diesen benachrichtigt wenn das Ereignis eintritt.

In der PHP Bibliothek PEAR gibt es dieses Pattern schon fertig programmiert: Event_Dispatcher.

1. Handler erstellen

Als Erstes benötigt man einen Handler der das Ereignis verarbeitet.

class Handler{
/**
* @param    Event_Notification
*/
public function getOnlogin(Event_Notification $oEvent_Notification){
$oValueObjects_User = $oEvent_Notification->getNotificationObject();
$aInfos = $oEvent_Notification->getNotificationInfo();
// mach irgendetwas
}
}

2. Handler registrieren

Jetzt muss der Handler beim Event Dispatcher registriert werden.

require_once 'Event/Dispatcher.php';
$oEvent_Dispatcher = Event_Dispatcher::getInstance();
$oEvent_Dispatcher->addObserver(array(new Handler(),'onLogin'),'onLogin');

Der erste Parameter ist ein PHP Callback. Als dritten Parameter kann man von eingrenzen von welche Objekten dieser Event geworfen werden darf.

3. Ereignis auslösen

Jetzt muss das Ereignis noch ausgelöst werden.

require_once 'Event/Dispatcher.php';
Event_Dispatcher::getInstance()->post($this,'onLogin',$aInfo);

Im dritten Parameter kann man noch Informationen in Form eines Array übergeben.

Nutzen

Veränderung vermeiden

Der Nutzen in dem Pattern liegt darin das man die Anwendung nicht mehr nachträglich anpassen muss um Erweiterungen einzubauen.

Verantwortlichkeiten sauber trennen

Die Verantworltichkeit der Kompontenten bleibt frei von Nebensächlichkeiten. Zum Beispiel kümmert sich dann die Login Komponente nur um das Login und sonst nichts. Alles andere wird über die Events abgearbeitet.

Fazit

Ich verwende dieses Pattern sehr viel und es macht die Anwendung wartbarer und den Einbau von Erweiterungen einfacher. In anderen Sprachen wie .NET ist das Pattern bereits in die Sprache eingebaut.