Wer viel programmiert, dem wird das klassiche MVC-Pattern (Model-View-Controller) sicherlich was sagen. Extremst vereinfacht ausgedrückt: der „Controller“ nimmt einen Request an (z.B. den Aufruf einer Unterseite), ruft das „Model“ auf um Daten aus der Datenbank zu erhalten, die dann an den „View“ weitergegeben werden, der das in Form einer HTML-Seite ausgibt. Eine ganz klassische Trennung von Datenbankzugriffen, Verarbeitung und Ausgabe. Was also zum Geier ist dann das HMVC-Pattern?

HMVC steht für „Hierarchical Model-View-Controller“. Der Unterschied ist hier einfach der, dass im Gegensatz zum klassischen MVC, wo es EINEN Controller mit EINEM Model und EINEM View gibt, es hier je nach Aufgabe mehrere Controller, Models und Views geben kann, die alle für sich genommen, mehrere kleine MVCs in einem großen Ganzen darstellen. Da ich nicht der allerbeste bin, was das Erklären von Softwarearchitekturen in einer akademischen Form angeht, verweise ich dreisterweise einfach mal auf folgenden Artikel, der dies sehr schön erklärt und anhand von Beispielen verdeutlicht: http://techportal.ibuildings.com/2010/02/22/scaling-web-applications-with-hmvc/ Lustigerweise wird dort auch alles anhand von Codebeispielen mit Kohana 3 erklärt.

Der Vorteil ist einfach: jede einzelne Funktion einer Webseite kann in ihrem eigenen kleinen MVC gebündelt werden, auf das andere Controller nach Belieben zugreifen können. Somit erhöht sich die Flexibilität und Wartbarkeit enorm. Im Extremfall könnte so ein Modul sogar auf einem ganz anderen Server liegen. Ein schönes Beispiel ist in dem oben verlinkten Artikel zu sehen, die Darstellung einer Profilseite eines Users. Ich habe es hier leicht abgeändert und vereinfacht übernommen. Unter anderem habe ich einfach mal die Fehlerbehandlung weggelassen und die Datenbankabfragen gleich durch das Doctrine-Equivalent ersetzt.

[sourcecode lang=“php“]
// Verarbeitet einen Request auf http://yourwebsite.com/username/
class Controller_Index extends Controller {

public function action_index() {
// Laden der Userdaten aus der Datenbank
$user = Doctrine_Core::getTable(‚Users‘)->find($this->request->param(‚user‘));

// Alle Nachrichten des Users laden.
$messages = Request::factory(‚messages/find/‘.$user->name)
->execute()
->response;

// Die index-Seite der User-Ansicht (View) ausgeben und dabei die Userdaten, Nachrichten und
// Verknüpfungen ans Template übergeben.
$this->request->response = View::factory(‚user/home‘, array(
‚user‘ => $user,
‚messages‘ => $messages,
));
}
}
[/sourcecode]

Innerhalb dieses Controllers wird noch ein weiterer aufgerufen: „messages/find/“. Dies ist dann wieder eine eigene Controller-Klasse („class Controller_Messages extends Controller {…}“ mit einer Funktion „find“. Das schöne hierbei ist, dass der erste Controller überhaupt nichts wissen muss, wie die Nachrichten geladen werden. Natürlich könnte man auch irgendwo ein „User“ Objekt initialisieren und eine Methode davon aufrufen um die Nachrichten zu bekommen. Aber wenn man evtl. mal die Funktion unter „messages/find“ an einer anderen Stelle braucht oder vielleicht sogar „stand alone“ aufrufen möchte, braucht man sich um die Objektinitialisierung keinerlei Gedanken machen.

Zwei weitere Sachen machen das HMVC Pattern, wie es Kohana 3 implementiert, sehr reizvoll. Man kann einen Controller bzw. eine „Route“ wie es eigentlich dann richtig heißt, auch erst dann ansprechen, wenn man das z.B. in einem Template braucht:

[sourcecode lang=“php“]

Die tolle Webseite

execute()->response;
?>

[/sourcecode]

Und was sich ebenfalls als nützlich herausstellen könnte: bei jedem Aufruf eines Controllers wird nachgeschaut, ob es die Funktionen „before“ und „after“ bei diesem Controller gibt. Die werden dann grundsätzlich jedesmal aufgerufen. So könnte man z.B. in der Funktion „before()“ benötigte Vorarbeit leisten, die dann in den jeweiligen einzelnen Methoden benötigt wird und dann wird in „after()“ wieder aufgeräumt. Quasi ein Konstruktor und Destruktor für die jweilige Controllerinstanz.

DooPHP bietet keine Unterstützung des HMVC-Patterns an. Allerdings sei zu seiner Ehrenrettung auch gesagt, dass Kohana 3 in dieser Hinsicht wirklich Pionierarbeit leistet, denn die allermeisten Frameworks kennen dies Pattern noch nicht.