Privat Projekt CMS

**bobby** · 01.09.2008 22:54

Ich klinke mich hier mal in die Diskussion ein:

zu 1) Wie Basti bereits gesagt hat, legst du für alle wichtigen Tabellen ein allgemeingültiges Model an. Im Controller extrahierst du dann die benötigten Informationen

PHP-Code:

 $users = Users::find(
    array('name' => 'LIKE "%name%"', ...),
    array('name' => $Request->get('name'))
);
$users->delete();

oder

PHP-Code:

 $user = new User();
$user->name = "Benutzer";
/** ... **/
$user->save();

zu 3) In Ruby on Rails gibt es das Konzept des Application-Layouts, d.h. das Ergebnis-View eines Controllers wird in ein anderes Template gerendert. (Kann natürlich pro Controller auch deaktiviert werden, falls nicht gewünscht)

application.phtml

HTML-Code:

<html>
<head>
  <title>Awesome title</title>
</head>
<body>
  <div id="content">
    <?php echo $yield ?>
  </div>
</body>

dispatcher.php (stark vereinfacht)

PHP-Code:

 ob_start();

$controller->{$action}();

$content = ob_get_clean();

// ...

print $view->render('application.phtml', array(
    'yield' => $content
));

So Geschichten wie Menüs etc., d.h. Templateteile die immer wieder benötigt werden heißen in Ruby on Rails "partials".
http://www.tutorialspoint.com/ruby-o...ails-views.htm

zu 6) Initialisier gleich zu Anfang (d.h. index.php o.ä - besser: lazy loading) deine Datenbankverbindung, da es selten einen Request gibt, der nichts aus der Datenbank benötigt.

Viele Grüße,
bobby.

(Ich will hier keinen zum RoR-Programmier machen, wollte ich nur klar stellen

)

**Basti** · 02.09.2008 09:31

Zitat von Victorious

Zu Punkt 1:
Hm dann habe ich da wohl noch nen verständnis problem. Wie genau soll das gehn? Bzw wie kann man sowas den umsetzten. Jedes script braucht ja andere Datensätze aus der Datenbank, z.B. news usw. Das ist ja ned so variable oder versteh ich das was falsch.

Es ist – zumindest für mich – nicht tauglich, alles, was mit News zu tun hat in einen Controller zu packen. Zudem greift ein News-Controller ja vielleicht auch noch auf andere Daten zu.

Mein CMS besteht z.B aus Modulen, die nach fein einstellbaren Regeln in die Seiten eingebunden werden und werden können. Da gibt es dann ein Modul, dass alle News ausgibt und ein anderes, das den Seiten eingefügt wird, um für diese einen News-Eintrag generieren zu lassen.

Beide Module (Controller) müssen an die News-Daten ran und es wäre unsinnig, da jetzt zwei Model-Klassen zu schreiben.

Andersrum gesagt: Die Datenobjekte und Peer-Klassen (bei mir sind das „Manager-Objekte“) haben keine Ahnung davon, von wem sie wozu benutzt werden, sondern repräsentieren für sich eben die Daten-Schicht mit allen dazugehörigen (bzw. insgesammt benötigten) Operationen.

Controller 1 sagt: User::get($this->Request->get(user_id)), Controller 2 sagt: $View->assign->('username', User::get($this->Sessin->get('user'))->name) usw.

Schau dir z.B. mal Propel an.
http://propel.phpdb.org/docs/user_gu...duction.ShowMe

zu Punkt 3:
Ja das mit den Views ist bei mir son problem, daher habe ich das erstmal so gelöst gehabt. Ich stell mir das nämlich so vor. Ich hab eine Index Seite die für alle gleich ist. Dann gibt es ein bereich wo das menü hinzugefügt wird und ein bereich wo der content hin kommt, sprich news, gästebuch what ever. Die menü einträge sollen später auch aus der DB kommen. Das heißt jedes template müsste gleich aussehn bis auf der content bereich, was ich ja ned so will. Das ganze ist eh noch so ne sache, es wird so oder so jedes mal die index.tpl geparst. Meine View ist ja nur eine TE die einfach die platzhalter ersetzt. Und was sollte den eigentlich in der Oberklasse rein beim Controller?

Du hast ja nicht genau einen Controller, den du aufrufst, sodern einen Baum von Controllern: z.B. ApplicationController > UserController > FormController > ButtonController oder wie auch immer du das dann gestaltest.

http://www.phpwact.org/pattern/model...ucturing_views

zu Punkt 5:
Damit das richtie Template geladen wird.

Aber gerade im Falle von Seiten wirst du ja nicht per URI übergeben, welches Template da eingebunden werden soll (und welcher Controller). Der Benutzer sagt dir ja nur: Gib mir die Startseite. Ob dann da News erscheinen, ein Warenkorb, eine Sprachauswahl oder ein Flash-Intro …

Bastian

**Victorious** · 02.09.2008 18:02

Hm, so wirklich schlau wird ich aus dem prople da nicht. Es sieht aber so aus, das man trozdem mehrere Models braucht für jede tabele eins oder seh ich das wieder falsch?

Und was sind Peer-Klassen bzw was sollen die genau machen?

Mein CMS soll auch nach Modulen arbeiten. Die man per Regeln einbinden kann oder nicht.Ohne Module wäre das ja nicht so schön erweiterbar.

Das mit den views ist mir auch ned so klar, bzw ich versteh zwar was es genau machen soll.Das es halt alles ausgibt, sowie zugrief auf die Daten hat, aber sie nicht verändern darf. Weiss zwar nicht wie man das in php realisieren könnte, wobei ich das bissel schwachsinig finde, da es ja somit 2 DB zugriffe immer gibt, einmal übern Controller und dann das View. Das mit dem Baum von ist mir auch klar. Ich hätte das so gedacht mit den Controller das jedes script seinen eignen Controller hat also sprich News, Gästebuch usw. Aber wenn ich so genauer betrachte ist das auch schwachsinig, da diese Controller ziemlich die selben Methoden hätten.

**dr.e.** · 02.09.2008 21:59

Hallo Victorious,

ich habe die Diskussion nicht bis ins Detail gelesen, doch zum Thema CMS ist im php.de-Forum sicher folgenden Post interessant: http://www.php.de/beitragsarchiv/439...higes-cms.html

Das Thema MVC und Templating, bzw. GUI-Modularisierung kann ich dir den Artikel PHP-Frameworks im Vergleich empfehlen. Dort werden insbesondere Möglichkeiten und Konzepte der Präsentationsschicht verglichen.

**Victorious** · 03.09.2008 22:55

Gibt es irgendwo nen Tutorial oder ne sehr gute beschreibung für ORM und deren Umsetzung. Würd das schon gerne selber versuchen hab mir aber schon mal propel angeschaut und PEAR

ataObject.

**dr.e.** · 12.09.2008 17:17

Hallo Victorious,

ich bin gerade dabei ein ORM-Tool für das APF zu schreiben. Vielleicht hilft dir dieser Forenbeitrag weiter: http://forum.adventure-php-framework...php?p=211#p211.

@Basti: endlich jemand der Verstanden hat, dass in Verbindung mit der 3-Schicht-Architektur nicht jeder MVC-Controller ein Model haben sollte. Danke! :)

**Victorious** · 13.09.2008 01:35

Ah denke werd ich mir mal anschauen. Hab aber da noch ne frage und zwar ist das ORM dann komplet die model schicht oder brauch ich trozdem noch was?
Zb. bei nen News-Skript das BBcode oder whatever nutz muss man ja die Daten aus der DB weiter verarbeiten mit replace functionen usw. Kommen dann diese replace funktionen dann in den controller der das dann weiter gibt an die view oder ins model? Wenn ja dann brauch man trozdem models für den controller.
Das widerum würde ja redundanz bedeuten was man nicht will. Oder hab ich da nen falschen ansatz? Bei mir soll jedes skript zb.(News, GB, Download usw) ein Controller sein, damit es halt schön erweiterbar ist.

**dr.e.** · 13.09.2008 10:34

Hallo Victorious,

gerne beantworte ich deine Fragen:

Ah denke werd ich mir mal anschauen. Hab aber da noch ne frage und zwar ist das ORM dann komplet die model schicht oder brauch ich trozdem noch was?

ORM steht für object (to) relational mapping. Zusammengefasst vermittelt diese Komponente zwischen der objektorientierten Welt deiner Anwendung und der relationalen Welt der Datenbank - in beide Richtungen. Die APF-Implementierung des OR-Mappers geht stellt dabei ein allgemeingültiges Domänen-Objekt zur Verfügung, das alle in der Datenbank abgelegten Objekte abbilden kann. Wenn du beispielsweise ein Gästebuch entwickelst, das die Objekte Guestbook und Entry und deren Beziehung kennt, dann kann dieses per Konfiguration definiert werden. Bei der Benutzung der API kannst du dann mit den entsprechenden Methoden Objekte oder Objektbäume aus der Datenbank laden und musst dich nicht mehr um das Schreiben der Statements und manuelle Mappen in Objekte kümmern.

Wenn du an einem konkreten Beispiel interessiert bist, kann ich dir gerne eines posten. Die genannte Seite (der Vollständigkeit wegen: http://adventure-php-framework.org/S...cher-OR-Mapper) beinhaltet jedoch ab Kapitel 4.1 Beispiele der Anwendung.

Zb. bei nen News-Skript das BBcode oder whatever nutz muss man ja die Daten aus der DB weiter verarbeiten mit replace functionen usw. Kommen dann diese replace funktionen dann in den controller der das dann weiter gibt an die view oder ins model?

Das Model - wie Basti schon formuliert hat - ist in komplexeren Applikationen nicht direkt mit dem Double Template und Controller "verbunden", sondern sollte ausgelagert werden. Das Model beschreibt im Allgemeinen den Zustand und das Verhalten der Applikation. Im einfachsten Fall kann das ein Datenobjekt sein, was in dem von dir beschreibenen Beispiel vielleicht sogar ausreicht. Um das jedoch korrekter zu gestalten, ist in diesem Beispiel Model und Domain-Objekt (=Daten-Objekt) getrennt zu sehen. Konkret bedeutet das: der Controller gibt sein Ergebnis an den View zur Darstellung.

Da der View möglichst wenig Logik inkludieren sollte, ist die Vorgehensweise einfach: der Controller bezieht die aktuell darzustellenden Objekte an Hand der Informationen aus dem Model - das z.B. Informationen enthält, welche Seite der News dargestellt werden soll. Weiterhin wird der Controller diese Informationen (=Domain-Objekte) verarbeiten (z.B. BB-Code-Highlighting) bevor diese an den View weitergegeben werden. STreng genommen, müsste sogar der Controller mit View-Hilfe die Ausgabe generieren (Stichwort: Listen-Generierung), setzt der Entwickler z.B. Smarty oder das APF ein, wird ihm das abgenommen.

Wichtig an dieser Stelle ist, dass versucht wird den View möglichst von Funktionen zu befreien (Stichwort: Kontrollstrukturen in Templates), da die Wiederverwendbarkeit sonst zu stark sinkt. BTW: zu diesem Zweck hat der Entwickler im APF die Möglichkeit wiederverwendbare TagLibs zu implementieren, die in beliebigen weiteren View-Templates eingesetzt werden können.

Wenn ja dann brauch man trozdem models für den controller.

Wie ich schon sagte, im einfachsten Fall ist das Verhalten hart durch den Controller definiert und ein Model überflüssig. Müssen Zustände hinsichtlich Verhaltensweisen einer Applikation gesprichert werden, ist ein Model - oft auch ein Model für eine größere Anzahl an Controllern - notwendig.

Das widerum würde ja redundanz bedeuten was man nicht will. Oder hab ich da nen falschen ansatz? Bei mir soll jedes skript zb.(News, GB, Download usw) ein Controller sein, damit es halt schön erweiterbar ist.

Redundanz wird hier dadurch vermiden, dass ein Model für mehrere Controller eingesetzt wird. Das ist gerade dann der Fall, wenn ein Modul (z.B. News-Ausgabe) aus mehreren Views besteht, die auf dieselben Model-Informationen des Moduls zugreifen (müssen). Aus meiner Erfahrung heraus sollte man das Pattern MVC immer im Kontext eines Moduls oder einer Software, nie aber autark betrachten. Gerade beim Thema HMVC, also dem hirarchischen Ansatz, der u.a. im APF verfolgt wird (Stichwort: DOM-Baum), ist es wichtig zwischen echtem Model und echten Daten-Objekt (=Domain-Objekt) zu unterscheiden. Weiterhin sollte man im Rahmen des Software-Designs auch über eine Kombination von MVC mit dem 3-Schicht-Modell nachdenken, daraus ergeben sich weitere Synergien. Beispiel: den oben beschriebenen OR-Mapper kann man ganz einfach als Datenschicht einsetzen. Die zwischen Präsentationsschicht und Datenschicht liegende Business-Schicht kümmert sich dann transparent um die BB-Formatierungsaufgaben und damit beschränkt sich der Controller in der Präsentationsschicht auf seine eigentlichen (Ausgabe-)Funktion. Sauberer geht es kaum.

Ich hoffe, ich konnte dir zum Thema Softwaredesign ein Stück mehr näher bringen.

**Victorious** · 13.09.2008 13:00

Dann müsste ja mein ansatz soweit schon richtig sein , wenn ich das ganze verstanden habe.

Ich liste mal auf was ich bisher so habe und für was das ganze ist, damit ich wirklich weiss das ich auf den richtigen weg bin.

Klassen die ich alle habe.

Registry(Singelton Klasse)
Request
Router
TemplateView
Controller
ErrorHandling

In der Registry Klasse werden bestimmte Objekte gespeichert die überall verfügbar sein müssen bzw variablen auch.

In der Request Klasse speichere ich ganzen Request, die für die weiterverarbeitung benötig werden.

Die Router Klasse sucht sich den richtigen Controller raus sowie benötige Methode.

TemplateView ist nur dazu zuständig um Templates zu parsen enthält, aber keinerlei logik.

Es gibt eine Abstrakte Klasse Controller so wie semtlich davon Abgeleiten Unter Controller.

ErrorHandling wie schon der name sagt bearbeitet die ganzen fehler die auftreten können, aber nicht sollten. Wenn nötig wird ein fallback ausgelöst.

So das ist was ich bisher so habe, wenn ich das richtig verstanden habe kann ich nun die API für die Datenschicht verwenden? Und falls es nötig ist ein Model dazwischen schalten, wenn mehrer Module auf die gleichen Seiten zugreifen muss?

PS:Ist es überhaupt schlimm APIs zu verwenden oder ist das ok?Weil mir fällt langsam auf wenn man wirklich alles komplet selber schreiben will, ist das ein haufen arbeit, und das mit dem ORM habe ich nun verstanden, wüsste zwar nicht wie ich das umsetzen kann, aber die theorie was dahinter steckt weiss ich nun. Ich glaub um nen ORM zu schreiben brauch man auch noch mehr Wissen Allgemein zu Datenbanken was die so alle können usw.

**Basti** · 13.09.2008 14:00

Christian, was ist für dich der Unterschied zwischen „Model“ und Daten- oder Business-Objekt? In meinem Verständnis besteht die Model-Schicht aus Datenbojekten, ev. noch Peer-Objekten, DAOs und Klassen, die den Zugriff auf die unterschiedlichen Speichermedien vermitteln.

Ein ORM erzeugt anhand einer Konfiguration Basisobjekte der unterschiedlichen Datenobjekte, die dann um eigene Funktionen erweitert werden können. (So gesehen hab ich übrigens kein ORM in meinem CMS umgesetzt, sondern lediglich allgemeine Datenobjekte, die halt ein paar Standard-Funktionen (sowas, wie getByPk()) umsetzen.)

Das heißt, dass alle Funktionen zur Manipulation von Daten (aber nicht etwa das Verhalten der Applikation) in die Datenobjekte oder die Peer-Klassen kommt, die von den vom ORM automatisch generierten Klassen abgeleitet sind.

Wie sich die Applikation verhält, also welche Daten wie verändert werden sollen ist in den Controllern definiert.

Die Frage nach der Logik in den Views ist ein klassischer „Konfliktpunkt“. In die Views gehötz „normalerweise“ sämtliche Darstellungslogik. Dazu gehötz dann also auch, wie der BB-Code dargestellt werden soll – wobei ich sowas dann eben auch in eine Helper-Klasse, ein Widget osr irgendwie sowas auslagern würde.

Unklarer wird sowas dann z.B. beim Paging von Inhalten. Hier wäre es eigentlich eine Sache der Darstellungslogik, eben nur die Gästebucheinträge 10 - 19 anzuzeigen. Macht aber keinen Sinn, erstmal alle 476 Einträge auszulesen und der View zu übergeben, damit diese dann die 10 Beiträge darstellen kann.

So gesehen ist hier der weiter oben angesprochene Ansatz, dass sich die View die Daten aus der Modell-Schicht zieht natürlich „sauberer“.

Ich gehe da allerdings recht undogmatisch ran und hab in meinem CMS viel rumprobiert. Mal so, mal so. Jetzt bin ich immer immer mal am Aufräumen und schreibe den Code um, wenn sich das eine Konzept bewährt hat und anderer Code noch auf einem andern beruht.

Aber die Aufbereitung von BB-Code gehört nach meinem Verständnis klar in die View-Schicht. Es ist ja auch so, dass diese ganz unterschiedliche Ausgaben aus den Daten produziert. In einem Fall wird der Inhalt direkt in ein Textfeld geladen, im anderen mit TML-Tags ersetzt. Weiter ist aber auch möglich, dass da ein PDF draus generiert wird, oder sonstwas. Die verwustung der BB-Tags ist also keine Methode der Datenschicht, sondern eine der (ggf. Medienspezifischen) Ausgabeschicht.

Aber klar, in ein Template sollte sowas natürlich nicht rein, sondern eben in eine Widget-Klasse, ein Template-Plugin, -Helper etc.

Bastian

**dr.e.** · 14.09.2008 10:24

Hallo Victorious,

Zitat von Victorious

Ich liste mal auf was ich bisher so habe und für was das ganze ist, damit ich wirklich weiss das ich auf den richtigen weg bin.

Ganz ehrlich: mit der Auflistung kann ich nicht bewerten, ob dein Weg stimmt. SOftware-Architektur beginnt eben nicht bei der Implementierung einer Registry oder eines Frameworks. Es beginnt auf einer Feature-Ebene, die fachliche Anforderungen beschreibt. Diese werden dann zu technischen Anforderungen heruntergrbrochen. Ist man im Besitz der technischen Anforderungen, kannst du dir z.B. Gedanken über den Einsat zeines Frameworks machen, sollte dich dieses in deinem Vorhaben unterstützen.

Worauf ich hinaus will: ein bottom-up-approach für ein CMS halte ich für nicht gangbar.

Zitat von Victorious

So das ist was ich bisher so habe, wenn ich das richtig verstanden habe kann ich nun die API für die Datenschicht verwenden? Und falls es nötig ist ein Model dazwischen schalten, wenn mehrer Module auf die gleichen Seiten zugreifen muss?

Das ist mir zu vage. Grundsätzlich gilt doch bei einem CMS, dass dieses Daten speichern muss. Hierzu sollte man eine allgemeingültige und für alle Bereiche und Module nutzbare Datenschicht erstellen. Diese muss grundsätzlich - möchte man OO im Applikationsdesign verwenden - ein Mapping bereitstellen und alle notwendigen Methoden aufweisen, die zum Erstellen/Updaten, Lesen und Löschen von wie auch immer gearteten Objekten. Um es dem Template-Entwickler einfach zu gestalten, sollte sich dieser nicht direkt mit der Datenschicht herumschlagen müssen, sondern es ist sinnvoll ihm eine Business-Komponente (oft "Manager" genannt) zu Seite zu stellen, der Top-Level-Methoden zur Erzeugung der Aus- und Eingabe besitzt. Die Daten, die hier behandelt werden, sollten in saubere Daten-Objekte (=Domain-Objekte) gekapselt sein. Würde z.B. der generische OR-Mapper des APF eingesetzt, so könnte man das generische Domain-Objekt bereits als solches nutzen. Vorteil: bei Änderung des Schemas muss keine Klassenänderung erfolgen. Das eigentliche Model müsste im Fall des CMS die Informationen

Welches Projekt ist gerade aktiv?
Welcher Navigationspunkt muss aktuell dargestellt werden?
Welche Sprache ist ausgewählt?
Evtl. Status über bestimmte weitere Funktionalitäten.

vorhalten. Du als Template-Entwickler kannst dann mit den Informationen aus dem Model und der Business-Komponente alle Aufgaben erledigen. Ist das nicht der Fall, muss Model oder Business-Komponente erweitert werden. Ersteres muss in diesem Fall dein Anspruch an die beiden Teile sein.

Zitat von Victorious

PS:Ist es überhaupt schlimm APIs zu verwenden oder ist das ok?Weil mir fällt langsam auf wenn man wirklich alles komplet selber schreiben will, ist das ein haufen arbeit, und das mit dem ORM habe ich nun verstanden, wüsste zwar nicht wie ich das umsetzen kann, aber die theorie was dahinter steckt weiss ich nun. Ich glaub um nen ORM zu schreiben brauch man auch noch mehr Wissen Allgemein zu Datenbanken was die so alle können usw.

Es ist in der Tat nicht schlimm fertige Tools (z.B. APF, ...) zu verwenden. Es bedeutet auch keinesfalls, dass du nicht fähig wärst, diese Komponenten selbst zu entwickeln! Umgekehrt ist es sogar notwendig bereits bestehende Dinge zu verwenden, da man sich Zeit und (ärgerliche Implementierungs-) Erfahrung spart - man kann nur profitieren. Und noch etwas: du darfst dich nicht der Illusion hingeben, dass ein Tool (insbesondere wird das leider in letzter Zeit im deutschsprachigen Raum missverständlich gesehen) dir die Architektur-Aufgabe abnimmt. Das ist de facto falsch! Die Architektur - und das ist ja das spannende - musst du schon selbst gestalten. Ich hatte dazu im php.de-Forum mal eine Diskussion mit einem geschätzten Mitglied und es hat lange gedauert ihm das schmackhaft zu machen. Die Wende konnte ich durch das Lesen des Gästebuch-Tutorials herbeiführen. Liest du dir das mit der Frage: "Wie viel APF steckt denn eigentlich dahinter?" durch, musst du sicher hinterher auch gestehen: "Fast nichts!".

Deshalb: mach dir erst Gedanken über das Software-Design/die Architektur!

**dr.e.** · 14.09.2008 10:45

Hallo Basti,

Zitat von Basti

Christian, was ist für dich der Unterschied zwischen „Model“ und Daten- oder Business-Objekt? In meinem Verständnis besteht die Model-Schicht aus Datenbojekten, ev. noch Peer-Objekten, DAOs und Klassen, die den Zugriff auf die unterschiedlichen Speichermedien vermitteln.

Das ist genau die missverständliche Sichtweise. Model ist im einfachsten Fall gleich einem Datenobjekt, darf das aber bei schon wenig höherer Komplexität nicht mehr sein. In Kombination von MVC, 3-Schicht-Architektur, DataMapper-Pattern und Domain-Object-Pattern - die sich übrigens prima ergänzen - ist es sogar notwendig zu trennen. Grund: die Applikation wird per se schon mal komplexer und setzt man auf HMVC, so gibt es sogar innerhalb einer Einheit (du kannst es Modul nennen) bereits eine Segmentierung, die jedoch alle auf gleichartige Informationen der Einheit zugreifen müssen (z.B. Sprache; siehe Model-Informationen im letzten Post).

Problem an der Gechichte ist nur, dass mit der Architektur von Web-Anwendungen Model-Informationen zunächst nicht sauber ausgemacht werden können, da HTTP statuslos ist. Mit Einführung der Session und Cookies ist das schon besser geworden, aber ein Request wird immer noch gesendet, abgearbeitet und gut. Insbesondere bei PHP gibt es z.B. keinen persistenten Speicherbereich, aus dem man sich bedienen kann und der einem bereits Business-Komponenten oder Model-Infortmationen liefert. Kurzum: die eigentlichen Model-Informationen stehen einem nur versteckt, nicht explizit, zur Verfügung!

Abhilfe kann hier die Implementierung nach dem FrontController-Muster schaffen. Das FrontController-Pattern beschreibt im wesentlichen den Vorteil, dass die Business-Schicht - diese sollte ja den Ablauf der Applikation steuern, nicht die Präsentationsschicht! - vor der Präsentationsschicht aufgebaut wird. Hier kann ich dann aus dem Request und aus der Session (evtl. auch Cookies) die eigentlichen Model-Informationen gewinnen und global zur Verfügung stellen. Bei einem CMS kann das z.B. die aktuell anzuzeigende Perspektive oder Sprache der Oberfläche sein. Operativ ist es einfach einfacher Informationen an einer zentralen und relevanten Stelle abrufen zu können als diese jedes mal wieder aus dem Request extrahieren zu müssen. Schadem, dass die neue APF-Seite noch nicht online ist, diese ist genau nach diesem Muster implementiert und es erleichtert sich so einiges.

Zitat von Basti

Ein ORM erzeugt anhand einer Konfiguration Basisobjekte der unterschiedlichen Datenobjekte, die dann um eigene Funktionen erweitert werden können. (So gesehen hab ich übrigens kein ORM in meinem CMS umgesetzt, sondern lediglich allgemeine Datenobjekte, die halt ein paar Standard-Funktionen (sowas, wie getByPk()) umsetzen.)

Das heißt, dass alle Funktionen zur Manipulation von Daten (aber nicht etwa das Verhalten der Applikation) in die Datenobjekte oder die Peer-Klassen kommt, die von den vom ORM automatisch generierten Klassen abgeleitet sind.

Das ist auch gut so. Ob du nun eine generische oder konkret implementierte Komponente in deiner abgeschlossenen Applikation hast, ist grundsätzlich nicht relevant. Bei der konkreten Implementierung ergibt sich einfach ein höherer Pflege-Aufwand.

Zitat von Basti

Die Frage nach der Logik in den Views ist ein klassischer „Konfliktpunkt“. In die Views gehötz „normalerweise“ sämtliche Darstellungslogik. Dazu gehötz dann also auch, wie der BB-Code dargestellt werden soll – wobei ich sowas dann eben auch in eine Helper-Klasse, ein Widget osr irgendwie sowas auslagern würde.

Da kommen wir endlich zum interessanten Punkt. Setzt man nur MVC ein, was du de facto nicht tust, sondern du hast mindestens eine 2-3-Schicht-Architektur, dann ist MVC ein Pattern der Präsentationsschicht. Nicht mehr und nicht weniger. Daraus ergibt sich aber, dass die Geschäftslogik in anderen Komponenten, nicht aber in der View- oder Controller-Komponente stattfinden sollte. Ich stimme zu, dass BB-Code-Formatierung (wie der Begriff ja schon sagt) in der Pres-Schicht stattfindet. Bitte verwende das aber nicht als allgemeingltige Regel, denn es gibt sehr viele Fälle, in denen das eben nicht so sein sollte (darf). Interessantes Beispiel ist die Berechnung des Alters eines Beitrages aus dem Erstellungsdatum des Beitrages und dem aktuellen Datum. Das ist Geschäftslogik und sollte auch in der dafür vorgesehenen Schicht durchgeführt werden.

Zitat von Basti

Unklarer wird sowas dann z.B. beim Paging von Inhalten. Hier wäre es eigentlich eine Sache der Darstellungslogik, eben nur die Gästebucheinträge 10 - 19 anzuzeigen. Macht aber keinen Sinn, erstmal alle 476 Einträge auszulesen und der View zu übergeben, damit diese dann die 10 Beiträge darstellen kann.

So gesehen ist hier der weiter oben angesprochene Ansatz, dass sich die View die Daten aus der Modell-Schicht zieht natürlich „sauberer“.

Paging von Inhalten ist Geschäftslogik und darf definitiv nicht in die Pres-Schicht. Die Pres-Schicht - so der Anspruch - sollte sich sogar nicht mal um die Darstellung des konkreten Pagers ("vor", "zurück", "Seite 1", "Seite 2", ...) kümmern müssen. Aus diesem Grund macht es Sinn die Pager-Funktionalität auszulagern. Dann hast du die Möglichkeit in der Business-Schicht deiner Anwendung diese Komponente zu nutzen ohne, dass du dich mit den Details rumärgern musst. Die Präsentationslogik deiner Anwendung kennt dann genau eine Methode, nämlich loadPagedList(), und diese kapselt bereits alles, was an dieser Stelle notwenig ist. Weiterhin sollte die Business-Schicht noch eine Methode zur Ausgabe des Pagers haben (z.B. getPager()) und fertig. Hierzu könnte für dich http://adventure-php-framework.org/S...usinessschicht und http://adventure-php-framework.org/S...tationsschicht (siehe Quellcode-Listing des Controllers) interessant sein.

**Victorious** · 14.09.2008 15:59

Woher weißte das ganze kram?^^ Mit den ganzen Pattern. Ich denke ich werd erstmal mein kram so weiter machen wie ich es bisher habe, um es später immer noch zu verbessern aus zu bauen usw. Weil wenn ich nun alles versuche das umzusetzen was du da geschrieben hast, hab ich ja noch lange nix was man zeigen könnte. Und ich glaub so lernt man um einiges besser, wenn man es schritt für schritt angeht und aus seinen fehlern lernt. Zu dem sind Pattern ja keine Standarts sondern nur hilfen die sich bewährt haben. Und ich muss trozdem sagen dafür das ich eigentlich noch nicht so lange das ganze mache, finde ich es schon echt gut.^^ Desto troz bin ich immer für jede Meinung Anregung offen.

Gruß
Alex

**dr.e.** · 14.09.2008 17:18

Hallo Victorious,

Zitat von Victorious

Woher weißte das ganze kram?^^ Mit den ganzen Pattern.

Ich lese Bücher, beschäftige mich mit Architekturen und versuche bei allem was ich tue zu lernen. Allerdings habe ich auch schon ein bischen Erfahrung in dem Bereich und arbeite als Software-Architekt.

Zitat von Victorious

Zu dem sind Pattern ja keine Standarts sondern nur hilfen die sich bewährt haben.

Das ist nicht ganz korrekt. Im Bereich der Softwarentwicklung sind die von mir beschrieben Pattern definitiv Standard. Jedes größere Projekt setzt Pattern ein, da man dadurch Standard-Probleme auch standardisiert lösen kann. Weiterer Vorteil: neue Leute können sich ganz schnell einarbeiten.

Damit du wirklich weiter kommst kann ich dir nur empfehlen, dich mit den Dingen, dich ich geschrieben habe intensiv zu beschäftigen, sonst hast du irgendwann ein Level erreicht, von dem aus du dich nicht mehr wirklich verbessern kannst, da dir die abstrakte Ebene fehlt.

Just my 2 cents...

**Victorious** · 14.09.2008 18:00

Klar werde ich mich damit beschäftigen. Immerhin steh ich noch relativ am anfang. Und einiges werd ich auch durch mein Studium kennen lernen. Aber hab da noch ne frage.

Was ist den nun genau der unterschied zwischen MVC und 3 Schichten Architektur? Versteh das nicht ganz.

**Basti** · 14.09.2008 18:16

Hallo Christian.

Zitat von dr.e.

Zitat von Basti

Christian, was ist für dich der Unterschied zwischen „Model“ und Daten- oder Business-Objekt? In meinem Verständnis besteht die Model-Schicht aus Datenbojekten, ev. noch Peer-Objekten, DAOs und Klassen, die den Zugriff auf die unterschiedlichen Speichermedien vermitteln.

Das ist genau die missverständliche Sichtweise. Model ist im einfachsten Fall gleich einem Datenobjekt, darf das aber bei schon wenig höherer Komplexität nicht mehr sein. In Kombination von MVC, 3-Schicht-Architektur, DataMapper-Pattern und Domain-Object-Pattern - die sich übrigens prima ergänzen - ist es sogar notwendig zu trennen.

Was zu trennen? „Model“ und Datenobjekt? Das Model repräsentiert die Daten, wie können die Datenobjekte aus dieser Schicht rausfallen? Das da natürlich auch Daten mit anderen Lebenszyklen (Request, Session) reingehören ist eh klar.

Abhilfe kann hier die Implementierung nach dem FrontController-Muster schaffen. Das FrontController-Pattern beschreibt im wesentlichen den Vorteil, dass die Business-Schicht - diese sollte ja den Ablauf der Applikation steuern, nicht die Präsentationsschicht! - vor der Präsentationsschicht aufgebaut wird.

Ich kann mir schwer Applikationen vorstellen, die keinen Front Controller haben oder gar die Steuerung in der Präsentationsschicht umgesetzt haben oder diese zuerst aufbauen – das macht ja null Sinn.

Setzt man nur MVC ein, was du de facto nicht tust, sondern du hast mindestens eine 2-3-Schicht-Architektur, dann ist MVC ein Pattern der Präsentationsschicht.

Huch? MVC ist ein Pattern der Präsentationsschicht? Die aussage musst du erläutern!

Ich stimme zu, dass BB-Code-Formatierung (wie der Begriff ja schon sagt) in der Pres-Schicht stattfindet. Bitte verwende das aber nicht als allgemeingltige Regel, denn es gibt sehr viele Fälle, in denen das eben nicht so sein sollte (darf). Interessantes Beispiel ist die Berechnung des Alters eines Beitrages aus dem Erstellungsdatum des Beitrages und dem aktuellen Datum. Das ist Geschäftslogik und sollte auch in der dafür vorgesehenen Schicht durchgeführt werden.

Genau genommen stimmt das natürlich, aber auch hier macht es wenig Sinn, dogmatisch ranzugehen.

Was das Paging betrifft, würde ich da allerdings (wie ja auch geschrieben) nicht unterschreiben, wo das „korrekter“ aufgehoben ist. Es macht durchaus Sinn, das Paging als Teil der Präsentationslogik zu betrachten. Die Trennlinie sehe ich zwischen dem „Was wird dargestellt“ und dem „Wie wird es dargestellt“. Und hier kann man eben genausogut fragen: „Wie werden die Gästebucheinträge dargestellt?“, wie eben auch „Welche Einträge wird dargestellt?“ (also was).

In Web-Anwendungen ist der Fall natürlich einfach, da man eben nicht erst alle Daten aus der DB ziehen und womöglich an den Client senden wird, der die Darstellung dann in mehrere Seiten umbricht.

Daher auch hier: Schauen, was taugt und nicht dogmatisch an den Konzepten festhalten, die womöglich in ganz anderen Kontexten entstanden sind (wie MVC).

Bastian

**dr.e.** · 14.09.2008 21:31

Hallo Basti,

Zitat von Basti

Was zu trennen? „Model“ und Datenobjekt? Das Model repräsentiert die Daten, wie können die Datenobjekte aus dieser Schicht rausfallen? Das da natürlich auch Daten mit anderen Lebenszyklen (Request, Session) reingehören ist eh klar.

Jetzt wird's tricky: das Model kann nur in sehr seltenen Fällen und bei ganz einfachen Applikationen gleich dem Daten-Objekt sein. Oft behandelt eine Applikation nicht nur ein Objekt, sondern eine Struktur von Objekten, deren Beziehung das Verhakten der Applikation beeinflusst, oder umgekehrt die Applikation auf Grund einer Beziehung agiert oder nicht. Nehmen wir ein Gästebuch als Beispie. Dieses hat streng genommen ein Entry und ein Comment Objekt. Die Beziehung zwischen Entry und Comment ist von der Qualität 1:n. Führen wir noch ein mandantenfähiges Gästebuch ein, so muss auch ein Guestbook-Objekt behandelt werden, das die jeweils relevanten Entries komponiert. Ist ein Gästebuch noch sprachabhängig, so kommt noch ein Objekt Language hinzu, das über entsprechende Beziehungen den Gästebüchern, Einträgen und Kommentaren Sprachen zuweist. All diese Strukturen können nicht in einem Model-Objekt abgebildet werden. Hier kann im Model nur recht wenig stehen. Anderes gesprochen: das Model muss in diesem Fall alle Informationen enthalten um mit Hilfe einer irgendwie gearteten Komponente (man nennt diese meißst Business-Schicht oder Manager) die Informationen ziehen zu können, die sie auch zur Darstellung benötigt.

Essenz: in komplexen Applikationen wird also ein Model sicher nicht gleich dem Datenmodell sein können. Auch wenn ein Modul aus mehreren Komponenten besteht, kann das Model nicht gleich der Business-Schicht sein, da sonst Informationen zu Darstellung nicht sauber gehalten werden können. Letzteres habe ich aus Erfahrung gelernt!

Zitat von Basti

Huch? MVC ist ein Pattern der Präsentationsschicht? Die aussage musst du erläutern!

Was ist es denn sonst? M steht für Model, das in einer 3-Schicht-Architektur in der Business-Schicht gelagert sein sollte, V für View, das etwas mit Darstellung - also Pres - zu tun hat und der Controller ist für die Ausgabe zuständig, also auch Pres. Geschäftslogik sollte, wie wir festgestellt haben, in einer eigenen Schicht gekapselt sein, von Datenlogik ganz abgesehen. Da die Pres-Schicht an vielen Stellen das Model braucht, ist dieses auch als Teil der Pres zu sehen. Wie du siehst: in jedem Satz kommt Pres vor...

Zitat von Basti

Daher auch hier: Schauen, was taugt und nicht dogmatisch an den Konzepten festhalten, die womöglich in ganz anderen Kontexten entstanden sind (wie MVC).

Ich bin nicht dogmatisch, ich beschreibe nur die Bedeutung der hier diskutierten Pattern. Das einzige Verhalten, dass ich mir in diesem Zusammenhang vorverfen lasse ist eine gewisse Konsequenz, denn Pattern grenzen sich deutlich ab und man sollte nicht den Fehler machen und diese zu stark verwässern, denn sonst wird der Vorteil schnell zum Nachteil. Gerade MVC wird in meinen Augen am meisten Falsch verstanden, oder anders formuliert: die wenigsten haben bisher die Synergien erkannt, die sich aus der Kombination von Pattern ergeben.

Und noch eins zum Schluss:

Zitat von Basti

Ich kann mir schwer Applikationen vorstellen, die keinen Front Controller haben oder gar die Steuerung in der Präsentationsschicht umgesetzt haben oder diese zuerst aufbauen – das macht ja null Sinn.

Ich behaupte, dass 80% der PHP-Scripts kein FrontController-Pattern implementieren.

**Basti** · 15.09.2008 10:03

Hi Christian.

[„Model“ und Datenobjekt?]

Dann hab ich dich nur falsch verstanden. Ich las oben folgenden Satz von dir: „Um das jedoch korrekter zu gestalten, ist in diesem Beispiel Model und Domain-Objekt (=Daten-Objekt) getrennt zu sehen.“ Und dann hab ich gedacht, du siehst an einem bestimmten Punkt ein Daten-Objekt nicht mehr quasi als Teilmenge des Modells an, sondern als etwas davon getrenntes.

Danke für die Ausführung – soweit ja alles klar.

Zitat von Basti

Huch? MVC ist ein Pattern der Präsentationsschicht? Die aussage musst du erläutern!

Was ist es denn sonst? M steht für Model, das in einer 3-Schicht-Architektur in der Business-Schicht gelagert sein sollte, V für View, das etwas mit Darstellung - also Pres - zu tun hat und der Controller ist für die Ausgabe zuständig, also auch Pres. Geschäftslogik sollte, wie wir festgestellt haben, in einer eigenen Schicht gekapselt sein, von Datenlogik ganz abgesehen. Da die Pres-Schicht an vielen Stellen das Model braucht, ist dieses auch als Teil der Pres zu sehen. Wie du siehst: in jedem Satz kommt Pres vor...

Du sprachst von „reinem“ MVC („Setzt man nur MVC ein, was du de facto nicht tust, sondern du hast mindestens eine 2-3-Schicht-Architektur, dann ist MVC ein Pattern der Präsentationsschicht.“). Aber auch so kann ich dem nicht folgen. funktioniert auch in meinen Augen nicht, MVC vor dem Hintergrund eines in eine 3-Schichten-architektur gepressten „MVC“ zu iskutieren und dann zu schauen, was es dann noch ist. Damit wird dieser Begriff einfach verwässert bzw. es ist eben kein MVC mehr.

Zitat von Basti

Daher auch hier: Schauen, was taugt und nicht dogmatisch an den Konzepten festhalten, die womöglich in ganz anderen Kontexten entstanden sind (wie MVC).

Ich bin nicht dogmatisch, ich beschreibe nur die Bedeutung der hier diskutierten Pattern. Das einzige Verhalten, dass ich mir in diesem Zusammenhang vorverfen lasse ist eine gewisse Konsequenz, denn Pattern grenzen sich deutlich ab und man sollte nicht den Fehler machen und diese zu stark verwässern, denn sonst wird der Vorteil schnell zum Nachteil. Gerade MVC wird in meinen Augen am meisten Falsch verstanden, oder anders formuliert: die wenigsten haben bisher die Synergien erkannt, die sich aus der Kombination von Pattern ergeben.

Oh, das war kein Vorwurf und ich meinte auch nicht dich damit.

Und noch eins zum Schluss:

Zitat von Basti

Ich kann mir schwer Applikationen vorstellen, die keinen Front Controller haben oder gar die Steuerung in der Präsentationsschicht umgesetzt haben oder diese zuerst aufbauen – das macht ja null Sinn.

Ich behaupte, dass 80% der PHP-Scripts kein FrontController-Pattern implementieren.

Naja, so ist PHP ja auch konzipiert. Aber ich meinte hiermit auch nicht „PHP-Skripts“, sondern eigenständige Software und … ehrlich gesagt hab ich gedacht, die Zeiten sind vorbei, in denen da so gepfuscht wird – und, natürlich kenne ich noch solche Software, stimmt schon. Ich hatte vor ein paar Jahren z.B. das Vergnügen, mit osCommerce arbeiten zu müssen. Oder mit Stud.IP, das in universitärem Umfeld entwickelt wurde und vom übelsten war, was man so verpfuschen kann.

Bastian

**dr.e.** · 16.09.2008 19:31

Hallo Basti,

Zitat von Basti

Aber auch so kann ich dem nicht folgen. funktioniert auch in meinen Augen nicht, MVC vor dem Hintergrund eines in eine 3-Schichten-architektur gepressten „MVC“ zu iskutieren und dann zu schauen, was es dann noch ist. Damit wird dieser Begriff einfach verwässert bzw. es ist eben kein MVC mehr.

Ich bin mir durchaus bewusst, dass die Kombination von Pattern nicht immer einfach ist. In vielen Fällen ergibt sich daraus sicher nichts gutes, im Fall von MVC und 3-Schicht-Architektur meiner Meinung nach schon.
In meinem Satz zu den drei Buchstaben hatte ich das Model mehr als Business-Schicht-Komponente gewertet. Letztlich ist es das auch (mehr oder weniger). Ziehe ich das Model in die Business-Schicht, so bleiben nur noch View und Controller in der Präsentation übrig. Diese können dann im Rahmen des MVC-Pattern natürlich auf das Model zugreifen - die Business-Schicht nutz im 3-Schicht-Modell ja auch eine Datenschicht um an Daten zu kommen - und dieses nutzen. Je nach "äußerer" Implementierung (Page- oder FrontController) ergeben sich dann leicht unterschiedliche Aufgaben von Controller und Model (bzw. Business-Schicht).

Im PHP-Bereich, der eigentlich per Design des HTTP-Protokolls vom PageController geprägt ist, stellt das natürlich eine Revolution dar, denn man ist gezwungen das FrontController-Pattern aufwändig zu implementieren, möchte man von echten Model-Informationen Gebraucht machen.

Schade, dass du nicht auf der OOP letztes Jahr warst, da gab es einen echt genialen Vortrag zum Thema "Kooperation und Koexistenz von Design-Pattern". Der ziehlte genau auf diese (und andere) Synergien ab.

Schade, dass ich nicht die Zeit habe, sonst würde ich mich gerne mit dir 2 Wochen wegsperren und das Thema CMS auf diese Weise implementieren.

**Basti** · 17.09.2008 10:23

Zitat von dr.e.

Schade, dass du nicht auf der OOP letztes Jahr warst, da gab es einen echt genialen Vortrag zum Thema "Kooperation und Koexistenz von Design-Pattern". Der ziehlte genau auf diese (und andere) Synergien ab.

Ich halte das auch für ein spannendes Thema. Meinte mit meiner Aussage eher, dass damit der Begriff „MVC“ so dann einfach nicht mehr passt. Die Prinzipien kannst du ja in alle Bereiche mehr oder weniger erfolgreich übertragen – sei es z.B. in den Aufbau einer Klasse. Alleine schon der ursprüngliche Sinn von GET- und POST-Requests geht ja genau in die Richtung und es gibt ja auch Ansätze, solche Abfragen in zwei Requests abzuarbeiten.

Schade, dass ich nicht die Zeit habe, sonst würde ich mich gerne mit dir 2 Wochen wegsperren und das Thema CMS auf diese Weise implementieren.

Wenns soweit ist, lass ich mein CMS mal von dir zerpflücken. Wird wohl noch ein paar Monate dauern, bis es veröffentlichungswürdig ist.

Bastian

Thema: Privat Projekt CMS

LinkBack

Themen-Optionen

Thema durchsuchen

Aktive Benutzer

Aktive Benutzer

Ähnliche Themen

[Grundlagen] Entwicklung eines Projektkonzeptes

welches CMS für Schülerzeitung?

CMS für Kunden aufsetzen

Developers-guide.net Projekt sucht willige Java Programmierer

Lesezeichen

Lesezeichen

Berechtigungen