Joomla! Programmierung/Model View Controller
Model View Controller (MVC, ‚Modell/Präsentation/Steuerung‘) ist ein Architekturmuster zur Strukturierung von Software-Entwicklung in die drei Einheiten Datenmodell (engl. model), Präsentation (engl. view) und Programmsteuerung (engl. controller). Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht.
Das MVC-Konzept wurde 1979 zunächst für Benutzungsoberflächen in Smalltalk durch Trygve Reenskaug beschrieben (Seeheim-Modell), der damals an Smalltalk im Xerox PAR arbeitete. Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf aller komplexen Softwaresysteme, teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen.
Inhaltsverzeichnis |
[Bearbeiten] Klassisches Architekturmuster
Die drei Komponenten hängen je nach Realisierung unterschiedlich stark voneinander ab:
[Bearbeiten] Modell (model)
Das Modell enthält die darzustellenden Daten und gegebenenfalls (abhängig von der Implementierung des MVC-Patterns) auch die Geschäftslogik. Es ist von Präsentation und Steuerung unabhängig. Die Bekanntgabe von Änderungen an relevanten Daten im Modell geschieht nach dem Entwurfsmuster „Beobachter“. Das Modell ist das zu beobachtende Subjekt, auch Publisher, also „Veröffentlicher“, genannt.
In Joomla! ist das Model hauptsächlich für die Beschaffung und Speicherung von Daten zuständig. Dabei ist es unerheblich, ob die Dateien aus einer Datenbank, einer Datei oder eines externen XML Feeds kommen. Vom View aus kann jederzeit mit $this->getModel() auf das zum View zugehörige Model zugegriffen werden.
[Bearbeiten] Präsentation (view)
Die Präsentationsschicht ist für die Darstellung der benötigten Daten aus dem Modell und die Entgegennahme von Benutzerinteraktionen zuständig. Sie kennt sowohl ihre Steuerung als auch das Modell, dessen Daten sie präsentiert, ist aber nicht für die Weiterverarbeitung der vom Benutzer übergebenen Daten zuständig. Im Regelfall wird die Präsentation über Änderungen von Daten im Modell mithilfe des Entwurfsmusters „Beobachter“ unterrichtet und kann sich daraufhin die aktualisierten Daten besorgen. Die Präsentation verwendet das Entwurfsmuster „Kompositum“.
In Joomla! ist der View zumeist zweigeteilt. Zu einem gibt es die Datei view.html.php, die für die Beschaffung der Daten zuständig ist. So werden in dieser z.B. die Methoden aus dem Model aufgerufen oder bestimmte Klassen eingebunden. Der zweite Teil ist eine Template Datei (default.php). In dieser geschieht die wahre Ausgabe. Alle von der view.html.php übergebene Dateien werden einfach ausgegeben. In der default.php sollten im Idealfall wirklich nur Ausgaben stehen und die Geschäftslogiken sollten schon in der view.html.php behandelt werden.
Die default.php ist auch die Datei, die mittels eines Template Overrides überschrieben werden kann. Deshalb ist es empfehlenswert Ausgaben nur in dieser default.php(bzw. zusätzliche AUsgabedateien) zu schreiben. Somit bleibt gewährleistet, dass ein anderer Nutzer ohne Hacks der original Datei das Aussehen der Ausgabe beliebig anpassen kann.
[Bearbeiten] Steuerung (controller)
Die Steuerung verwaltet eine oder mehrere Präsentationen, nimmt von ihnen Benutzeraktionen entgegen, wertet diese aus und agiert entsprechend. Zu jeder Präsentation existiert ein Modell. Es ist nicht die Aufgabe der Steuerung, Daten zu manipulieren. Die Steuerung entscheidet aufgrund der Benutzeraktion in der Präsentation, welche Daten im Modell geändert werden müssen. Sie enthält weiterhin Mechanismen, um die Benutzerinteraktionen der Präsentation einzuschränken. Präsentation und Steuerung verwenden zusammen das Entwurfsmuster „Strategie“, wobei die Steuerung der Strategie entspricht. Der Controller kann in manchen Implementierungen ebenfalls zu einem „Beobachter“ des Modells werden, um bei Änderungen der Daten die View direkt zu manipulieren.
In Joomla! ist der Controller für die Instanzierung des Models und dem Aufruf des entsprechenden Views verantwortlich. Dabei kann man bei Bedarf neben dem Standardcontroller auch alternative Versionen laden, die für bestimmte Zwecke erstellt worden sind. So könne die verschiedenen Controller verschiedene Speicheraufrufe an das Model veranlassen und man kann je nach Bedarf den gewünschten Controller laden.
[Bearbeiten] Nicht definierte Funktionalitäten
Da das MVC-Muster in verschiedenen Programmiersprachen unterschiedlich realisiert werden muss, gibt es selbst keine genaue Definition über die Positionierung der Geschäftslogik innerhalb der MVC-Klassen. Diese kann je nach Anwendungsfall besser im Controller aufgehoben sein oder auch in das Modell verlagert werden. In der Praxis finden sich unterschiedliche MVC-Programmiergerüste: Einige schreiben strikt vor, wohin die Geschäftslogik gehört, andere überlassen diese Entscheidung dem Softwareentwickler.
In Joomla! wird die Hauptgeschäftslogik in der view.html.php behandelt. Diese Datei ist im Prinzip die Schnittstelle zwischen der Datenhaltungsschicht (Model) und der Präsentationsschicht (default.php).
In ähnlicher Weise ist der Ort für die Validierung der Benutzereingaben nicht definiert. Einfache Formatvalidierungen können bereits im View realisiert werden. Validierungen, welche stärker die Geschäftslogik berücksichtigen müssen, werden eher im Model oder im Controller implementiert.
In Joomla! passiert die Validierung der Usereingaben zumeist im Controller, bevor mittels diesen Daten auf das Model zugegriffen wird.
Auch für die Formatierung der Rohdaten und die Internationalisierung ist nicht definiert, wo diese erfolgen. Aus Gründen der Entwicklungs-Effizienz bietet es sich oft an, diese im Model zu integrieren, so dass man sich beim View auf die Erstellung von Widgets oder Templates beschränken kann. Andererseits werden dadurch Aspekte der Darstellung in das Model verlagert, was zur Grundidee durchaus im Widerspruch steht. Als Variante bietet es sich daher auch an, hierfür eigenständige Funktionsbereiche vorzusehen, die man dann weder Model, View oder Controller zurechnen muss.
In Joomla! kann man dafür alternativ Helperklassen oder eigene Methoden im View erstellen.
[Bearbeiten] Beispiele
ToDo Joomla!spezifisches Beispiel einfügen
