In Foren macht man interessante Beobachtungen. So konnte ich z.B. die Unsitte beobachten, bei jeder zweiten Frage mal grundsätzlich ein fröhliches “Iiiihhh… Das ist ja gar nicht MVC. Mach mal deine Hausaufgaben.” um die Ohren geprügelt bekommt. Google geizt auch nicht mit weiterführenden Informationen. Und dort einer ganzen Fülle an Begrifflichkeiten. Schichtenmodell, 3-Tier, Business Logic, …
Woher kommt eigentlich diese MVC-Geilheit? Muss das wirklich sein, um objektorientierte, ja überhaupt eine halbwegs brauchbare PHP-Anwendungen zu schreiben? Selbstverständlich. Sonst würde ja nicht jedes moderne Framework, das etwas auf sich hält, darauf basieren. Oder?
Dem möchte ich in dieser Artikelserie einsteigerfreundlich auf den Grund gehen.
- Was ist MVC (Diese Seite)
Informationen zum Grundgedanken “MVC” sowie zu gängigen Problemen eben damit.
- MVC für Einsteiger – eine Alternative?! (folgt)
Vorstellung einer einfachen Alternative zum MVC-Ansatz. Eine Lösung für alle, die Objektorientierung oder Technikgequassel nichts abgewinnen können.
- Eine spezifische Umsetzung (folgt)
Meine Implementierung, die ich augenblicklich umsetze, wird vorgestellt und “zur Schlachtung freigegeben”. Kommentiert, kritisiert, diskutiert, erweitert nach Belieben.
Intention
oder: Warum dieser Text?
Bei mir sorgte die generelle “Möglichkeit zur Implementierung der Business Logic abhängig von Anwendungsfall und Implementierung der MVC-Architektur” erst für fragendes Kopfschütteln und anschließend für einige schlaflose Nächte. In denen habe ich mich nochmals intensiv mit Software-Design auseinandergesetzt. Ergebnis ist dieser kleine Exkurs mit der Zielgruppe “Einsteiger”, also Hobby-Coder, die einfach ohne große Einleitung und Wörterbuch der Software-Architektur programmieren wollen.
Daher versuche ich nach der Definition – frei nach dem Prinzip “Quo errat demonstrator” (sic!) – einen Weg aufzeigen, wie jeder, der schon die ein oder andere Codezeile geschrieben hat, ohne langwieriges Studium von Design-Patterns, abstrakten Beispielen und übermäßigem Objektorientierungsvokabular einen absolut gleichwertigen und leicht verständlichen Ersatz für MVC erhält.
Ich gehe im folgenden davon aus, dass du:
- schon das ein oder andere PHP-Projekt umgesetzt hast,
- Funktionsdefinition und -aufruf keiner weiteren Erklärung bedürfen,
- die Grundlagen der Objektorientierung halbwegs kennst, mindestens jedoch weißt, dass man in PHP Objekte mit
“$instanz = new Klassenname;” instanzieren kann, deren Methoden mit
“$instanz->Methode();” aufruft und dir die Bedeutung und Unterschiede der Begriffe
Klasse, Instanz und Methode grundlegend klar sind,
- dich nicht mit mir darüber streitest, dass die Trennung von HTML und PHP ( in den meisten Fällen ) recht sinnvoll ist, und du dies auch regelmäßig halbwegs sauber löst ( ebenfalls – in den meisten Fällen)
- allerspätestens jetzt weißt, das die Begriffe Entwurfsmuster und (Design-)Pattern “bewährte Lösungs-Schablonen für wiederkehrende Entwurfsprobleme in Softwarearchitektur und Softwareentwicklung” sind.
Doch nun – genug der Einleitung, Butter bei die Fische – Ein MVC-Ersatz
Dafür müssen wir wissen, was genau wir eigentlich ersetzen wollen. Also, was ist und welchem Prinzip folgt…
MVC?
Um es möglichst allgemeinverständlich und das Prinzip erläuternd zu halten, werde ich Begriffe und Abläufe im Folgenden zugunsten der Verständlichkeit stark vereinfachen (und/oder verunstalten). Der Softwarearchitekt, der sich hierher verirrt hat, möge mir den ein oder anderen hochgerollten Zehnagel verzeihen.
Das MVC-Pattern entstand während der 1970er aus/für/mit Smalltalk. Smalltalk war eine der ersten populären objektorientierte Programmiersprachen, und hat u.a. Java stark beeinflußt.
MVC – Model, View, Controller – beschreibt eine Verfahrensweise, die Anwendung in voneinander weitgehend unabhängige Teilbereiche logisch aufzuspalten. Damit sollen die typischen Ziele der Objektorientierung umgesetzt werden, die da beispielsweise wären
- einfache Updates durch modularen Aufbau
(“Modul austauschen” <=> “Ändere Zeile 1 dies, Zeile 21 das, …”);
- Verschiedene Ausgabearten (“normales HTML”, Ajax, RSS-Feed, PHP auf Kommandozeile, etc)
-> Wiederverwendbarkeit von Standardfunktionen
- Austauschbarkeit von Komponenten (z.B. verschiedene Datenbankarten)
- …
Dazu teilt der typische PHP-MVCler die Anwendung in 3 Teilbereiche auf – Hier vorgestellt anhand eines Onlineshops:
| Views |
Ausgabe(formate) – Bei einer Artikelverwaltung beispielsweise ein oder mehrere HTML-Generatoren (Templates), PDF-Katalog-Generator, etc… |
| Models |
darzustellende Anwendungsdaten.
Also z.B. der darzustellende Artikel (ArtNr,Name, Beschreibung, Lieferant, …), bzw. eine Artikelliste. |
Als Anwendungslogik (auch Business Logic, Geschäftslogik ) wird der Teil der “Software” bezeichnet, der die wesentliche Problemstellung löst, im Gegensatz zur Implementierung der technischen Umsetzung. In unserem Onlineshop werden hier Artikeldaten aus der Datenbank ausgelesen und für die Ausgabe vorbereitet.
Grundsätzlich “darf” der Ablauf der Anwendungslogik sowohl im Model als auch in Controller stattfinden.
Die direkte Verknüpfung und Abhängigkeit von den Anwendungsdaten (z.B. Datenbankbankmanipulation) ergibt oft die logische Zuordnung zum Model.
Das Konzept der Business Logic ist abstrakt und unscharf, da die beiden “Logik-Ebenen” nur bedingt trennbar sind. (siehe Erklärungstext)
|
| Controller |
Die Anwendungssteuerung.
Fungiert oft als direkte Schnittstelle zwischen View & Modul und steuert den Programmablauf. |
Man kann also sagen, dass zusätzlich zu der Trennung von Ausgabe und Programmlogik (HTML<->PHP) noch der PHP-Programmteil weiter unterteilt wird (Anwendungs- und Aufgabenabhängig); So können im Model wiederverwendebare Module entwickelt werden (z.B. eine Klasse zur Datenbankmanipulation), die unabhgängig von der jeweiligen Anwendungssteuerung agieren – also unabhängig, ob es sich nun um eine Adressverwaltung oder das Update einer CMS-Website geht.
Umgekehrt können verschiedene Module (bzw. Modulteile) verwendet werden, obwohl eine identische Anwendungssteuerung verwendet wird. Die selbe Adressverwaltung wird in unterschiedlichen Firmen also mal mit einer MySQL-, mal einer Oracle-Datenbank eingesetzt.
An sich eine tolle Sache, oder?
Wie du in der Tabelle liest, kann die Anwendungslogik (Business Logic) sowohl im Controller, als auch im Model untergebracht werden.
Anhand unseres Beispieles: Das Auslesen einer Preisinformation aus der Datenbank – ein ziemlich klares Model. Nun benötigen wir noch den Abzug eines Bestandskundenrabattes von 10%. Wird die Rabattstufe nun von der Anwendungssteuerung mit übergeben und im Model abgezogen, Ergebnis ist also der tatsächliche Endpreis? Oder nach Rückgabe des Nettopreises erst in der Anwendungssteuerung abgezogen, hieraus der Bruttopreis berechnet? Was widerspricht am wenigsten unserem Konzept von klarer Aufgabentrennung?
Alleine durch die unterschiedlichen möglichen Orte der Geschäftslogik sind “unterschiedliche” MVC-Implementierungen möglich. Aber dir ist sicher auch nicht die Formulierung “der typische PHP-MVCler” entgangen. Denn “das” MVC gibt es eigentlich gar nicht.
Definitions- und andere MVC-Probleme
Das MVC-Pattern entstand als Lösung für eine Smalltalk-Anforderung. War die View im Smalltalk-Damals wie im PHP-Heute für die Präsentation, also die Auslieferung der “Ausgabe”, zuständig, fangen wie schon angesprochen, spätestens beim Ort der Geschäftslogik die Diskussionen an.
Ähnlich undefiniert ist ein Ort für die Validierung der Benutzereingaben. Einfache Formatvalidierungen können im View realisiert werden (JS-”Validierung”…hüstel) – wird die Geschäftslogik stärker berücksichtigt, bieten sich eher Controller oder Model an. Und dank Ajax hat der findige Web 2.0 – Entwickler noch eine zusätzliche Sandbank zu umsegeln.
Effizienterweise integriert man Rohdatenformatierung und die Internationalisierung im Model, kann sich dadurch in der View auf die Template-Erstellung konzentrieren. Nur ist die Vermischung von Darstellung und Logik widersprüchlich zur Grundidee.
Noch offensichtlicher werden die Unterschiede allerdings beim Controller. In Smalltalk, in den späten 1970ern, hatte dieser die Aufgabe, die Anwendung von der Eingabe abzuschotten. Zum Beispiel war er dafür zuständig, Mausereignisse einem konkreten Bildschirmbereich zuzuordnen. Im Klartext: Den Klick auf den Koordinaten XY dem Button auf den selben Koordinaten. Nennen wir das mal “Eingabecontroller”.
Sieht man sich die heute verwendeten Controller an, findet sich davon nicht viel wieder. Denn heute sind es meist “Applikationscontroller”, eben unsere Anwendungssteuerung. Die “Eingabe” ist nämlich bereits aufgearbeitet und automatisiert – dem gemeinen PHPler auch als $_REQUEST et cetera bekannt.
Dieser Rollentausch ist übrigens kein Resultat der speziellen Bedingungen von Webanwendungen oder PHP.
So existiert bei den Microsoft Foundation Classes und auch bei Swing (Java) kein Conroller. Bei MS heißt es Document-View, bei Swing Model-Delegate. Mit anderen Worten – Der Controller verschmolz mit der View bzw. bei Swing mit Anzeige- und Eingabekomponente Delegate. Einfacher Grund: 30 Jahre Weiterentwicklung. Die ursprünglichen Aufgaben des Controllers übernehmen Bibliotheken, die wir mittlerweile ganz selbstverständlich voraussetzen. Der Controller wurde arbeitslos – bis Sun in J2EE zwei Varianten (Model 1 & 2) des MVC-Musters eingeführt (und inzwischen wieder verworfen) hat. Und aus letzerer resultiert das heutige Verständnis und der Einsatz von MVC.
Es sei nochmal darauf hingewiesen – Heute wird “MVC” als Architekturmodell verstanden und genutzt. Ursprünglich war es das niemals, sondern stattdessen eine Lösung für eine bestimmte Teilaufgabe: Trennung von Aktion und Präsentation.
Nachdem wir nun einige Probleme und Definitions- und Anwendungsprobleme diskutiert haben – geht’s im nächsten Teil weiter mit der Erstellung unserer MVC-Alternative.
Und bis dahin – Fröhliches Coden, allerseites
Letzte Kommentare