[dr.e.]

Hallo Basti,

Zitat von Basti

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.

Ich freue mich auf die Diskussion darüber!

[Victorious]

Huhu,

Ich hab da immer noch paar Verständis probleme, der verschiedenen Pattern, die hier genannt werden. Da ich ein perfektionist bin, würde ich die gerne beseitigen um gleich was vernüftiges produzieren, was sauber und strukturiert geschrieben ist.

Ersten zur 3-Schichten-Architectur , wie kann man sowas eigentlich bei einer Webapplication implementieren. Ich hab da mal im netz nach geschaut und hab öfters gefunden, dass das so aufgebaut ist.

• Datenbankserver
• Applikationserver
• Webserver

Sowas habe ich bei mir auch in den Studienunterlagen nach lesen können, aber sowas wäre dann ja nicht wirklich implementierbar bei einer webapplication. Und das MVC-Pattern aggiert dann zwischen den 3-Schichten bzw auch gelesen das MVC auch eine 2-Schichten-Architectur ist. Und das MVC die Presentation Schicht ist, was ja auch schon gesagt wurde. Was ist genau gemeint mit Busines-Schicht gemeint,Geschäfts-Logik und Datenschicht bzw was die beinhalten. Und was genau muss ein FrontController beinhalten, hab das bisher nur verstanden das er einfach den richtigen Controller raussucht der gebraucht wird und ihn dann zurverfügung stellt, gehört da noch was rein? Und als letztes Controller und Model, View. Der Controller sollte doch nix anderes machen als die geforderte action zu behandeln,aber keinerlei logik wie berechnungen usw?
Die View stellt das ganze dann dar entweder als gui oder als html seite, da gehören dann sachen wie Darstellungslogik mit rein oder nicht? Und was mir am meisten Probleme macht ist das Model. Ich hatte das so gelernt gehabt das dort Datengespeichert werden bzw verwaltet und semtliche berechnung dort stattfinden. Und wenn ich das richtig verstanden habe sind Daten-Objekte nichts anderes, wie eine Datenbank, nur das es Objekte sind und man unabhängig ist welche Datenbank nutzt.

Am besten wären vlt konkrete beispiele.
Ich hoffe das macht euch keine Umstände.

Gruß
Vic

[dr.e.]

Hallo Victorious,

sorry, dass ich noch nicht geantwortet habe, Gründe kennst du aus der PN. Ich werde versuchen Anfang der nächsten Woche näher auf deine Fragen einzugehen, da ich das in dieser Woche nicht mehr schaffe.

So long,
Dr.E.

[dr.e.]

Hallo Victorious,

grundsätzlich würde ich dir raten, ein Buch über Pattern und vor allem über die Koexistenz und Kooperation von Pattern zu konsumieren. Das hilft dir sicher!

Nun zu deinen Fragen:

1. 3-Schicht-Architektur:
3-Schicht-Architektur bedeutet kurz zusammengefasst die Trennung einer Applikation in die Schichten

* Datenschicht
* Businessschicht
* Präsentationsschicht

Diese Art der Trennung ist auch für eine Webanwendung möglich und oft auch sehr sinnvoll. Die Unterscheidung zwischen Datenbankserver, Applikationserver und Webserver ist eher eine infrastrukturelle Gliederung, weniger eine auf Software-Ebene.

2. MVC
Das MVC-Pattern beschreibt die Trennung von Anzeige-Logik, Anzeige-Darstellung und Applikationsinformationen. Zu letzterem können im einfachsten Fall auch daten einer Applikation gezählt werden. Da der Großteil der Bereiche zur Präsentationsschicht zählen, ist in der Kooperation der beiden Pattern in der Präsentationsschicht einzusortieren. Ziehst du das M in die Business-Schicht und stellst diese allgemein verwendbar zur Verfügung, zerteilst deine Präsentationsschicht in kleinere MVC-Einheiten, kandest du beim HMVC, oder beim APF-MVC, wie es das Adventure PHP-Framework implementiert. MVC hat jedoch separat betrachtet nichts mit 2- oder 3-Schicht-Architektur zu tun.


3. Geschäftslogik
Die Geschäftslogik in eine eigene Schicht (im Sinne des 3-Schicht-Musters) zu packen kommt aus dem Gedanken der Wiederverwendbarkeit. Lagere ich Funktionen aus, kann ich diese beispielsweise in Front- und Backend-Komponenten wiederverwenden. Die beiden Komponenten unterscheiden sich dann lediglich in der GUI. Inhalte der Biz-Schicht sind die Koordination der Applikation, Speicherung und Aufbereitung der Benutzereingaben etc. Die Sicht trennt sich jedoch in einer 3-Schicht-Architektur deutlich von der Datenschicht. Letztere ist für das Laden und Speichern von Objekten zuständig.


4. FrontController

Und was genau muss ein FrontController beinhalten, hab das bisher nur verstanden das er einfach den richtigen Controller raussucht der gebraucht wird und ihn dann zurverfügung stellt, gehört da noch was rein? Und als letztes Controller und Model, View. Der Controller sollte doch nix anderes machen als die geforderte action zu behandeln,aber keinerlei logik wie berechnungen usw?

Der FrontController ist vor Allem bei Web-Anwendungen interessant. Die Problematik ist, dass Webanwendungen per se keine immerzu existente Business-Schicht besitzen, da HTTP statuslos ist (Sessions mal ausser Betracht gelassen). Mit dem FrontController hingegen wird dieses Problem insofern gelöst, als dass dieser vor dem Laden und Erzeugen der Präsentationsschicht, die Business-Schicht mit dem Model der applikation aufbauen kann. Damit steuert - wie eigentlich sinnvoll - die Biz die Pres und nicht umgekehrt.

5. Diverses

Die View stellt das ganze dann dar entweder als gui oder als html seite, da gehören dann sachen wie Darstellungslogik mit rein oder nicht?

Richtig, der View sollte so logikarm wie möglich gehalten werden. Frameworks in denen PHP als Template-Sprache verwendet wird und nicht XML / HTML / XSL ist das IMHO nicht so sauber, da bei den genannten Tolls eine weitaus größere Gefahr besteht, den View mit zu viel Logik zu versehen und somit die Wiederverwendbarkeit zu gefährden. Ist die Logik jedoch sauber ausgegliedert, kann für einen beliebigen Controller ein anderer View geladen werden, der eine Ausgabe anderer Art und mit gleichen Inhalten erzeugen kann.

Und was mir am meisten Probleme macht ist das Model. Ich hatte das so gelernt gehabt das dort Datengespeichert werden bzw verwaltet und semtliche berechnung dort stattfinden. Und wenn ich das richtig verstanden habe sind Daten-Objekte nichts anderes, wie eine Datenbank, nur das es Objekte sind und man unabhängig ist welche Datenbank nutzt.

Da bin ich etwas anderer Meinung. Man sollte hier das reine Model (Statusinformationen der Applikation) und die Businesslogik aufspalten. Kennt die Businessschicht das Model, oder ist es ein und die selbe Komponente, so läufst du Gefahr, dass die Applikation nicht wiederverwendbar ist, da die Abhängigkeiten zu stark sind. Aus diesem Grund behandle ich das Model als eigenständige Status-Informationskomponente, auf Basis derer Daten über eine Business-Klasse (oft Manager genannt) bezogen werden können. Im Beispiel würde das bedeuten, dass dein (MVC-)Controller per Informationen im Model (z.B. "Welches Gästebuch bin ich gerade?") von einer Manager-Instanz per getPagedList() bezieht. Die Business-Schicht kümmert sich dann um das Paging und das Beziehen der Daten aus der Datenschicht. Letztere wiederum kennt die Datenbank und die zugehörige Datenstruktur. Auch Aufgabe der Datenschicht ist es in komplexeren Strukturen, die aus der Datenbank ausgelesenen Daten in ein Format zu bringen, mit dem die Anwendung (=Business- und Präsentationsschicht) umgehen können. Dies wird auch oft mit Mapping, bzw. OR-Mapping beschrieben. In diesem Zusammenhang kann auch das Domain-Object-Pattern interessant für dich sein.

Am besten wären vlt konkrete beispiele.
Ich hoffe das macht euch keine Umstände.

Nein, Beispiele habe ich schon zur Genüge fertig. Die beiden besten sind

* http://adventure-php-framework.org/S...ktion-Tutorial
* http://adventure-php-framework.org/S...ebuch-Tutorial

Solltest du dazu Fragen haben, dann her damit!

[Victorious]

Hallo Dr. E.,

erstmal danke für die genaueren Beschreibung, werde mir aber aufjedenfall Bücher darüber besorgen, sowie deine tutorials durch arbeiten/lesen, dass ganze wird nur bissel dauern da ich momentan sehr viel andere dinge zu tun habe.^^ Sobald ich fragen werde ich mich wieder an dich wenden.