zietlow.net

Ziel ist es das MVC Prinzip und dessen Umsetzung im Zend Framework zu verstehen.
Damit wird die Grundlage für die Entwicklung im Zend Framework gesetzt - Unabhängig der Version.

---

Sinn eines Software-Architekturmusters

Software gleicht an vielen Stellen dem Hausbau. Ab und an leider auch dem Städtebau…
Wenn wir – als Programmierer (Maurer) oder Software-Architekt / Entwickler (Architekt) – eine Software „bauen“ möchten, sollten wir uns am Anfang einen Plan dieser Software machen

Software-Architekturmuster stellen uns für den Plan und für den Bau ein Grundgerüst zur Verfügung, nach dem wir die Software logisch aufbauen können.
Sie sind aber keine Garantie für eine stabile und sichere Anwendung, da es sich um ein logisches Konzept handelt.

Vorteile und Ziele eines Architekturmusters:

• Architekturmuster schaffen Ordnung
• Die Kommunikation wird vereinfacht
• Einmal erlernt, ist der Aufbau der Software logisch
• Leichte Erweiterbarkeit
• Leichte Änderbarkeit
• Möglichkeit zur Wiederverwendung von Code

Nach Architekturmuster können Software-Anwendungen entwickelt werden.
Oft kommt hierfür ein Framework zum Einsatz, welches nach dem Architekturmuster entwickelt wurde und die Umsetzung und Einhaltung dieses Architekturmusters vereinfacht.

Eines der meist verwendeten Software-Architekturmuster ist das MVC (Model-View-Controler),
welches näher beschrieben werden soll.

Grundaufbau des MVC

Das MVC Architekturmuster gibt drei Trennungen vor:

• Model (Modell)
• View (Präsentation)
• Controller (Steuerung)

Model (Modell)

Zuständigkeit des Models:

• Daten
  Beispiel: aus einer Datenbank werden Daten abgefragt.
• Geschäftslogik
  Beispiel: „Wenn Produkt MwSt-Pflichtig, dann schlage 19% drauf.“

View (Präsentation)

Zuständigkeit der View:

• Anzeige von Daten (aus dem Model)
• Anzeigelogik
  Beispiel: „Wenn diese Kennzahl so, dann zeige Schaltfläche X an.„
• Benutzerinteraktion bereitstellen
  Schaltflächen, Textfelder etc.

Controller (Steuerung)

Zuständigkeit des Controllers:

• Verwaltet Views
• Steuert wann welche View angezeigt wird
• Verwaltet Benutzereingaben
  Gibt diese an die View weiter

Zusammenspiel in klassischen Fenster Applikationen

In klassischen Fenster-Applikationen bilden Controller und View die Benutzeroberfläche,
da der Controller die Eingaben entgegen nimmt, diese ans Fenster (View) weiterleitet.
Die View kennt dabei sein Model und leitet die Eingabe zur Bearbeitung weiter.
Grund hierfür ist, dass die Entwicklung oft hinter einem optischen Objekt (z.B. einer Schaltfläche) in einer Methode (z.B. „Klick auf die Schaltfläche“) steckt.
Diese Methode kommuniziert dann mit dem Model.

Das ergibt oft folgende Kommunikation:

Controller <-> View <-> Model

Zusammenspiel in Web-Anwendungen / im Zend Framework

In Web-Anwendungen steckt hinter einer Schaltfläche erst einmal noch keine direkte Logik.
Das drücken dieser Schaltfläche wird erst an den Server übertragen, der wiederum,
muss hierfür eine passende Aktion ausführen und sendet ein Ergebnis zurück.

Im Zend Framework ergibt sich daraus folgende Kommunikation:

Model -> Controller <-> View

Die View greift - idealerweise - auf die Daten aus dem Model nur zu,
wenn der Controller diese übergeben hat,
dadurch entsteht keine direkte Kommunikation zwischen Model und View.

Hinweis: Es gibt mittlerweile Web-Entwicklungen die das den klassischen Fenster Applikationen gleich machen (Microsoft ASP .NET und in Anlehnung daran das PHP Framework Prado).
Diese lassen sich – fasst – so wie Fenster-Anwendungen entwickeln und setzen das intern wieder so um, dass das auch im Web funktioniert.

Voraussetzung: OOP

Nachfolgend geht es um die konkrete MFC Umsetzung im Zend Framework.
Hierfür sollte OOP (Objektorientierte Programmierung) und alle damit verwendeten Begriffe kein Fremdwort sein. Als Auffrischung empfehle ich den Wikipedia Eintrag zu OOP.

Für Diejenigen die sich mit OOP noch gar nicht auskennen:
Generell ist es sinnvoll / notwendig sich das OOP Prinzip an zueignen, wenn man das MVC Prinzip nicht nur konzeptionell sondern auch die technische Umsetzung verstehen möchte.
Die Umsetzung von MVC basiert meistens immer auf dem OOP Konzept.

Für Diejenigen die OOP kennen, kann ich nur empfehlen sich mit Design Patterns (Entwurfsmustern) zu beschäftigen. Es erleichtert das Zend Framework zu verstehen und ist natürlich auch für eigene Entwicklungen extrem nützlich – wenn man auf OOP setzt…

MVC im Zend Framework

Das Zend Framework ist nach dem MFC Architekturmuster aufgebaut.
Die MVC Theorie sollte klar sein, ab hier wird jetzt die technische Umsetzung im Zend Framework beschrieben.

Model

Derzeit – und ich denke auch in Zukunft – gibt es keine generelle Komponente für das Model.
Wir wissen, dass das Model die Geschäftslogik und die Daten beinhaltet.

Bei dem Model handelt es sich also um Klassen, die Daten aus Datenbanken, Web Services, Feeds, Konfigurationsdateien, Dateisystem und anderen Quellen „her holen“ und diese – je nach Geschäftslogik – verarbeiten.
Das ist meist so individuell das es keinen Sinn macht das Model vorzuschreiben.

Doch das Zend Framework bietet für die verschiedensten Zugriffe Unterstützung an, zum Beispiel:

• Zend_Db: auf Datenbanken zuzugreifen
• Zend_Service_*: Entsprechenden Webservices aufrufen
• Zend_Config: Konfigurationsdateien auszulesen
• …

View

Standardmäßig gibt es die Klasse Zend_View, die als Template Engine PHP verwendet und vom Anfang an aktiv ist.
Eine eigene View kann erstellt werden, Sie muss lediglich das Interface Zend_View_Interface implementieren.
Ich gehe jedoch bei der kommenden Beschreibung von der Zend_View und deren Standradkonfiguration aus.

Die Zend_View hat die Aufgabe die View Scripts zu verarbeiteten, die für uns den View Part im MVC Modell darstellen.

View Scripts

Die eigentliche Anzeige und die Anzeigelogik befindet sich in den View Scripts.

• Befinden sich im Verzeichnis:
  „application/views/scripts“
• Endung „.phtml“, deutet an das sich darin PHP und HTML befindet.
• Ausgabe von Variablen: <?=$this->content ?>
• View Helpers:
  • Erweitern die Funktionalität von Zend_View
  • Aufruf wie eine Methode von Zend_View
    <?= $this->formText(’username’) ?>
  • Eigene View Helper könnten geschrieben werden
  • Anwendungsmöglichkeiten:
    • Datenabruf (z.B. Hinzufügen eines del.icio.us Feeds)
    • Umändern der Ausgabe (z.B. Wikitext in HTML konvertieren)
    • Anzeigelogik (z.B. Anzeigen des Logins, wenn nicht angemeldet)
    • Wiederverwendbare Ausgaben (z.B. eine Suchbox)
• Filter
  • Kann den Inhalt vor der Ausgabe filtern
  • Es können eigene Filter geschrieben werden
  • Anwendungsmöglichkeiten:
    • Inhalt von HTML zu PDF umwandeln
    • Inhalt von HTML zu JSON umwandeln
    • HTML über Tidy laufen lassen

Controller

Im Zend Framework ist das der Action Controller:

• Verwaltet die Anfrage
• besteht aus mehreren Actions
• Aktion
  • öffentliche Mehtode
  • Aufbau des Namens: [Name]Action
  • „indexAction“ wird aufgerufen falls keine Action angegeben ist
  • „init“ wird bei der Initialisierung aufgerufen
  • definiert welches View Skript ausgegeben werden soll
    (Std: [Controllername]/[Actionname] im View Script Verzeichnis)
  • Kommuniziert mit dem Model
  • leitet Daten – z.B. aus dem Model oder Request – an die View
  • Action Helper,
    • Wiederverwendbare Funktionalitäten
    • Aufruf aus allen Action Controllern heraus
    • Automatische Prozesse die in den Action Controllern ausgeführt werden
      (über die init oder die preDispatch Methode)
    • Initialisierung bei der Benutzung (on demand) oder nach Registrierung
    • Funktionalitäten die man später auslagern möchte

Zusammenspiel

Das grundlegende Zusammenspiel wurde oben schon beschrieben,
hier geht es wieder um die technischere Umsetzung.

Alles hat einen Anfang – die Bootstrap-Datei

Eine Datei muss die Startdatei der Applikation sein,
diese Datei nennt sich im Zend Framework „Bootstrap“ (Lader / Ladeprogamm) bezeichnet.

Aufgaben der Bootstrap-Datei:

• Benötigte Skripte einbinden (include_once…)
• Evtl. Konfigurationsdateien einlesen
• Objekt-Initialisierung

Controller sollen aufgerufen werden – der Front Controller

Das Zend Framework bietet Standard an, wie Controller und dessen Aktionen aufgerufen werden können. Im Standard schaut die URL wie folgt aus:
[Controllername]/[Actionname]/[Parametername1]/[Parameterwert1]/[usw.]

Damit jetzt auch der entsprechende (Action) Controller und die entsprechende Aktion aufgerufen werden, gibt es den Front Controller.

Aufgaben des Front Controllers:

• Verwaltet die Anfragen
• Leitet Anfragen an die / den entsprechenden „Action Controller“
• Gibt die Ausgabe zurück

Der Front Controller ruft damit die den entsprechenden Action Controller und die Action auf.

Und jetzt…

Ab hier geht es jetzt wie oben beschrieben weiter.
Die Action kommuniziert mit dem Model und gibt eine Ausgabe (View) zurück.
Der Front Controller kann auch noch andere Actions ausführen, die wiederum eine View zurück geben.
Am Ende gibt der Front Controller die Views aus.

Eine handvoll Eingriffsmöglichkeiten

Das System stellt eine Vielzahl von Eingriffsmöglichkeiten parat,
um Funktionalitäten zu erweitern oder hinzufügen.
Hier eine kleine Auswahl:

Request Object (Anfrage Objekt)

Alle Informationen zur Benutzeranfrage

Router (Vermittler)

• Teilt die Anfrage auf, in
  • Controller
  • Action
  • beliebige Parameter (die im Controller entsprechend an Model/View übergeben werden)
  • Standardmäßig: [Controllername]/[Actionname]/[Parametername1]/[Parameterwert1]
• Es können eigene Routen definiert werden, Beispiel: „login/[Benutzername]/[Passwort]“

Dispatcher (Abfertiger / Umschalter)

• Verbindet die geteilte Anfrage des Routers auf eine Klasse, Methode
• Ruft die Methode auf

Response Object (Antwort Objekt)

• beinhaltet alle Ausgaben
• gibt diese aus

Plugins

• Aufruf bei Front Controller Geschehnissen
• Übergreifende automatische Ausführung von Aktionen

Jetzt los an die Entwicklung

Nach dieser Anleitung sollte klar sein, wie das MVC Architekturmuster funktioniert, wie dieses im Zend Framework umgesetzt wurde und wie man in dessen Ablauf sinnvoll eingreifen kann.
Damit sollte der Grundstein gelegt sein, um das Zend Framework zu verstehen und damit zu entwickeln.
Sobald dieses Prinzip verstanden wurde, ist der Rest „nur“ noch ein Kennen der Klassen, Methoden und eine Sammlung von Erfahrungen.

Quellen und weiterführende Links:

• Zend MVC Quick Start (PDF, englisch)
• Zend Framework Reference Guide
• MVC (Wikipedia)
• Architekturmuster (Wikipedia)
• OOP (Wikipedia)
• Bestehender Diskussions-Thread zum Artikel
• Etwas tiefere technische Beschreibung des Ablaufs (englisch)