Gästebuch Tutorial

Hier dreht sich alles um die auf der Webseite veröffentlichten Tutorials. // This forum is all about the APF tutorials.
Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 01.09.2009, 21:37:13

Hi Doc,

Wenn ich für jedes Modul ein und die selbe User Tabelle nutze, setzt das doch voraus, dass meine User für jedes Modul exakt gleich sind? Schränke ich mich damit nicht unnötig ein?

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Gästebuch Tutorial

Beitrag von dr.e. » 01.09.2009, 22:21:40

Hallo Thalo,

du schränkst dich damit nicht ein. Grund: ein Benutzer besteht in jeder Applikation aus den gleichen Basis-Daten. Sofern du Modul-abhängige Konfigurationen oder Nutzerdaten benötigst, werden diese üblicherweise unterhalb des Moduls komponiert und zum Benutzer als "Profil" assoziiert. So kannst du die Stammdaten zentral verwalten und bleibtst trotzdem offen für Erweiterungen von Modulen.
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 01.09.2009, 23:35:21

Hi Doc,


Allmählich frag ich mich ob das so eine gute Idee war :lol:

Kannst du mir ein paar Tipps geben, wie ich schwerwiegende Architektur Fehler vermeide die ich später durch ein Refactoring ohne weiteres nicht mehr beheben kann?

Wie ich hier sehe, gibt es doch einige Dinge, wie man seine Architektur schnell gegen die Wand fährt. Macht mir doch ernsthafte Sorgen.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Gästebuch Tutorial

Beitrag von dr.e. » 02.09.2009, 21:41:52

Hallo Thalo,
Allmählich frag ich mich ob das so eine gute Idee war :lol:
Das was eine gute Idee war?
Kannst du mir ein paar Tipps geben, wie ich schwerwiegende Architektur Fehler vermeide die ich später durch ein Refactoring ohne weiteres nicht mehr beheben kann? Wie ich hier sehe, gibt es doch einige Dinge, wie man seine Architektur schnell gegen die Wand fährt. Macht mir doch ernsthafte Sorgen.
Ich denke, du musst dir keine Sorgen machen. Das APF "zwingt" dich auch ohne, dass du es merkst schon dazu deinen Code zu strukturieren. Allein die Trennung von Ausgabe von Logik (Templates und Controller) ist schon ein Schritt in die richtige Richtung. Sofern du dir schon Gedanken über die Segmentierung von Modulen gemacht hast - was ja der Fall ist - ist das ein weiterer Schritt in Richtung guter Architektur. Nun ist es interessant, wie du die Module koppelst. Dies ist an sich der schwerste Part, bei dem man aber zunächst auch Erfahrungen sammeln muss. Wenn du mal einen Prototypen fertig hast, wirst du beim Hinzufügen eines neuen Moduls (z.B. Blog) sehen, wo es Haken und Ösen gibt und wo noch nachgebessert werden muss.

Grundsätzlich gelten folgende Guidelines:
  • Die Datenhaltung sollte von der eigentlichen Applikation getrennt werden. Dies hilft, sich über die eigentlich in der Anwendung benötigten Daten Gedanken zu machen. Stichwort: Domänen-Modell.
  • Ähnliche Aufgaben sollten über eine allgemeingültige Lösung abgedeckt werden, so bist du bei jeder neuen Aufgabe schneller in der Implementierung und die Qualität der Software steigt stetig.
  • Einzelne Module sollten möglichst entkoppelt von einander sein, damit es möglich ist abgetrennte und widerverwendbare Software zu schaffen. Als Kopplung kannst du die URL oder in deinem Fall ein gemeinsames Model nutzen.
Was die Kopplung von Modulen angeht, habe ich in einer Applikation auch mal die Idee verwirklicht, Komponenten in eine Anwendung zu injizieren. Konkret war das ein eingeloggter Benutzer und der Manager, der zum Laden und Verwalten von Benutzern zuständig war. Das habe ich so realiert, dass der aktuell eingeloggte Benutzer per Front-Controller-Action von aussen in das Model des Moduls injiziert wurde und im gleichen Atemzug die Business-Komponente der Anwendung den UsermanagementManager eingetrichtert bekam. Dadurch wurde für das Modul - in deinem Fall z.B. die Blog-Verwaltung - eine Umgebung geschaffen, bei der es sich selbst nicht um die Abhängigkeiten von aussen kümmern musste.

Umsetzen kannst du das mit dem APF einfach so, dass du dir in einer Front-Controller-Action eine Singleton- oder SessionSingleton-Instanz des Models der Anwendung holst und dort den aktuell eingeloggten Benutzer einsetzt (z.B. setLoggedInUser()). Die Injektion einer Business-Komponente in einer andere kannst du mit Hilfe des DIServiceManager regeln, der es erlaubt, eine Service-Komponente mit einer anderen zu initialisieren. Voraussetzung des Ganzen ist jedoch, dass du einen Rahmen schaffst, der sich um Login etc. kümmert und in einer weiteren FC-Action diese Informationen zur Injektion in das Model eines Moduls vorbereitet (Authentifizieren des Nutzers, Laden der Nutzerdaten, Speichern in der Session, ...).

Fang einfach mal mit der Implementierung eines Moduls und der Backend-Integration an, dann können wir die aufkommenden Fragen an einem konkreten Beispiel diskutieren. Und: keine Angst, so sehr kannst du dein Design mit deinen Vorüberlegungen nicht versauen! :)
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 20.09.2009, 19:24:01

Hi Doc,

Nur zum besseren Verständnis. Das gehört alles zum Modell oder? (dem M in MVC)

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Gästebuch Tutorial

Beitrag von dr.e. » 20.09.2009, 19:36:36

Hi Thalo,

das ist mehr oder weniger alles Model - oder genauer - Business-Schicht. Wenn es dir hilft, können wir die Zuordnung gerne an konkreten Teilen deiner Software besprechen.
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 20.09.2009, 20:05:11

dr.e. hat geschrieben:Hi Thalo,

das ist mehr oder weniger alles Model - oder genauer - Business-Schicht. Wenn es dir hilft, können wir die Zuordnung gerne an konkreten Teilen deiner Software besprechen.
Hi Doc,

Ich hab mich noch nicht getraut, etwas umzusetzen :D. Mir ging es ferner um ein Buch was ich mir vor kurzem zugelegt habe. (http://openbook.galileocomputing.de/oo/)

Dort wird unter anderem geschrieben, dass...

MVC ist keine komplette Architektur.

In der Praxis und in der Literatur haben wir aber häufiger eine Interpretation von MVC gesehen, die dieses Muster zur kompletten Architektur für eine Applikation erhoben hat. Außerdem wird häufig auch die Rolle des Modells überdehnt, indem diesem die Verantwortung für Geschäftslogik, Persistenz oder andere zentrale Aspekte zugeschoben wird.

Sie sollten auf keinen Fall MVC mit der Schichtenarchitektur verwechseln. Das Modell ist nämlich nicht für die Umsetzung der Schicht der Anwendungslogik zuständig. Natürlich können beide Aufgaben (Bereitstellung der Anwendungslogik und Darstellbarkeit in der Präsentationsschicht) in der Praxis von denselben Objekten übernommen werden. So können Sie natürlich eine Enterprise Java Bean als Modell verwenden, um diese direkt über die Präsentationsschicht darzustellen. Die Modell-Eigenschaft ist dabei aber nach wie vor völlig unabhängig von den anderen Eigenschaften der EJB, wie z. B. die Fähigkeit, Daten persistent zu machen.
(http://openbook.galileocomputing.de/oo/ ... #Xxx999152)

Nach meiner Auffassung, liegt die Businesslogik aber im Model? :ugeek:. Und viel wichtiger, gehört das MVC überhaupt zur 3-Tier Architektur? Ich habe schon öfter von dir gelesen, dass du die beiden gleichsetzt. Aber genaugenommen stimmt das nicht, oder?

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Gästebuch Tutorial

Beitrag von dr.e. » 20.09.2009, 20:32:00

Hi Thalo,
Ich hab mich noch nicht getraut, etwas umzusetzen :D.
Dann wird es höchste Zeit. Es mag zwar am Anfang holprig erscheinen, jedoch wird das mit der Zeit und vor allem mit der Erfahrung besser.
Nach meiner Auffassung, liegt die Businesslogik aber im Model? :ugeek:. Und viel wichtiger, gehört das MVC überhaupt zur 3-Tier Architektur? Ich habe schon öfter von dir gelesen, dass du die beiden gleichsetzt. Aber genaugenommen stimmt das nicht, oder?
OK, das ist ein etwas komplexeres Thema, denn hier geht es um die Kooperation von Pattern - eines meiner Lieblings-Themen. :)
Nach meiner Auffassung, liegt die Businesslogik aber im Model?
Nein, diese sollte nicht im Model, sondern in einer eigenen Business-Komponente liegen.
Und viel wichtiger, gehört das MVC überhaupt zur 3-Tier Architektur?
Ja, es ist eine Verfeinerung der 3-Schicht-Architektur und ich stimme dem Kommentar im OpenBook vollständig zu! :)
Ich habe schon öfter von dir gelesen, dass du die beiden gleichsetzt.

Eigentlich nicht. Zitat aus http://adventure-php-framework.org/Seite/013-Grundlagen:
Das Model-View-Controller-Pattern ist dabei ein Pattern der Präsentations-Schicht. Die Präsentations-Schicht - oder kurz genannt "pres" - ist für die Darstellung der Applikation in einer (HTML-)GUI zuständig. Sie kennt alle HTML-Elemente und ebenso die Business-Schicht (biz), die der Präsentations-Schicht Daten und Informationen zur Art und Inhalt der Darstellung liefert. Innerhalb der biz-Schicht werden die Geschäftsprozesse der Anwendung gekapselt und ausgeführt. Die Datenschicht beschäftigt sich einzig und allein mit der Daten-Accquise und -Persistenz. Hierzu kennt sie die Datenquelle und besitzt Mechanismen mit denen Daten aus der Datenquelle gelesen und als auch gespeichert werden können.
Aber genaugenommen stimmt das nicht, oder?
Nein, MVC ist nicht eine komplette Architektur, da gibt es deutlich mehr. Leider wird das auf den Webseiten anderer Frameworks oft anders verkauft und ich diskutiere schon sehr lange in Foren mit den Leuten, dass das eben nicht das Kriegs-entscheidende Pattern ist. Schön, dass du das sofort erkannt hast! :)
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 20.09.2009, 21:30:42

Hi Doc,
dr.e. hat geschrieben:Hi Thalo,
Ich hab mich noch nicht getraut, etwas umzusetzen :D.
Dann wird es höchste Zeit. Es mag zwar am Anfang holprig erscheinen, jedoch wird das mit der Zeit und vor allem mit der Erfahrung besser.
Ich bin eher der Meinung, dass das vorgenommene Projekt um einiges zu hoch für mich ist :?
dr.e. hat geschrieben:
Nach meiner Auffassung, liegt die Businesslogik aber im Model?
Nein, diese sollte nicht im Model, sondern in einer eigenen Business-Komponente liegen.
Ich habe dich doch gerade noch gefragt, ob der Service, Mapper und Domänenobjekt zum Model gehören? Versteh ich da etwas komplett falsch?
dr.e. hat geschrieben:
Und viel wichtiger, gehört das MVC überhaupt zur 3-Tier Architektur?
Ja, es ist eine Verfeinerung der 3-Schicht-Architektur und ich stimme dem Kommentar im OpenBook vollständig zu! :)
Kannst du vielleicht etwas näher darauf eingehen, was du mit "Verfeinerung" meinst? Ich lese immer öfter, besonders in englischen Foren, dass das MVC nicht zu der 3-Tier Architektur (Schichtenarchitektur?) gehört..
dr.e. hat geschrieben:
Ich habe schon öfter von dir gelesen, dass du die beiden gleichsetzt.

Eigentlich nicht. Zitat aus http://adventure-php-framework.org/Seite/013-Grundlagen:
Das Model-View-Controller-Pattern ist dabei ein Pattern der Präsentations-Schicht. Die Präsentations-Schicht - oder kurz genannt "pres" - ist für die Darstellung der Applikation in einer (HTML-)GUI zuständig. Sie kennt alle HTML-Elemente und ebenso die Business-Schicht (biz), die der Präsentations-Schicht Daten und Informationen zur Art und Inhalt der Darstellung liefert. Innerhalb der biz-Schicht werden die Geschäftsprozesse der Anwendung gekapselt und ausgeführt. Die Datenschicht beschäftigt sich einzig und allein mit der Daten-Accquise und -Persistenz. Hierzu kennt sie die Datenquelle und besitzt Mechanismen mit denen Daten aus der Datenquelle gelesen und als auch gespeichert werden können.
Das versteh ich nun gar nicht. :geek: MVC gehört zur Präsentationsschicht? Ich dachte nur der View? :oops:
dr.e. hat geschrieben:
Aber genaugenommen stimmt das nicht, oder?
Nein, MVC ist nicht eine komplette Architektur, da gibt es deutlich mehr. Leider wird das auf den Webseiten anderer Frameworks oft anders verkauft und ich diskutiere schon sehr lange in Foren mit den Leuten, dass das eben nicht das Kriegs-entscheidende Pattern ist. Schön, dass du das sofort erkannt hast! :)

Tue ich das denn? Oder erkenne ich nur die Ironie in dem Satz nicht? ;)
Ich bin fühle mich ziemlich vor dem Kopf gestoßen, da ich mich auf die Aussagen der Framework-Entwickler verlassen habe. Was genau bildet denn dann die Architektur? Die kooperation aus allen Patterns? Bin bisher davon ausgegangen, dass das MVC meine Architektur vorgibt.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Gästebuch Tutorial

Beitrag von dr.e. » 20.09.2009, 22:59:29

Hallo Thalo,
Ich bin eher der Meinung, dass das vorgenommene Projekt um einiges zu hoch für mich ist :?
OK, dann lass uns das erst mal theoretisch klar kriegen.
Ich habe dich doch gerade noch gefragt, ob der Service, Mapper und Domänenobjekt zum Model gehören? Versteh ich da etwas komplett falsch?
Ich fürchte, wir hatten uns da missverstanden. :( Die Zuordnung ist folgende:

Code: Alles auswählen

Business-Schicht:
  -> Service
  -> Domänen-Objekt
  -> Model
Daten-Schicht:
  -> Mapper
  [-> Datenbank-Abstraktion (z.B. connectionManager des APF)
Präsentations-Schicht
  -> View
  [-> Controller]
Kannst du vielleicht etwas näher darauf eingehen, was du mit "Verfeinerung" meinst? Ich lese immer öfter, besonders in englischen Foren, dass das MVC nicht zu der 3-Tier Architektur (Schichtenarchitektur?) gehört..
Das MVC-Pattern gehört definitiv nicht zur 3-Schicht-Archiektur, sondern ist ein eigenes Pattern. In Kooperation mit diesem stellt es jedoch eine Möglichkeit dar, die "große weite" Präsentations-Schicht noch weiter zu untergliedern. Die Pres-Schicht beinhaltet quasi alles, was mit der Darstellung einer Applikation zu tun hat. Wie das nun im Detail strukturiert ist, dabei kann das MVC-Pattern helfen. Ein Äquivalent dazu ist der DataMapper für die Daten-Schicht. Dieser definiert auch genauer, wie die Daten-Schicht aufgebaut/strukturiert ist.
Das versteh ich nun gar nicht. :geek: MVC gehört zur Präsentationsschicht? Ich dachte nur der View? :oops:
Nein auch der Controller. Das Model kannst du nun zur Präsentation oder zur Business-Schicht zählen, das ist nicht so wichtig. Grund: in der 3-Schicht-Architektur hast du oft sogar 2 Modelle deiner Anwendung: die eigentlichen Daten (Domänen-Objekte) und ein Model, das zur Darstellung der Komponenten genutzt wird, sprich den Zustand der Applikation speichert. Das ist sowohl für die Pres- als auch für die Biz-Schicht von Bedeutung.
Tue ich das denn? Oder erkenne ich nur die Ironie in dem Satz nicht? ;)
Das war ernst gemeint! Ich finde es gut, dass du genau nachfragst und differenzieren möchtest. Ehrlich! :)
Ich bin fühle mich ziemlich vor dem Kopf gestoßen, da ich mich auf die Aussagen der Framework-Entwickler verlassen habe. Was genau bildet denn dann die Architektur? Die kooperation aus allen Patterns? Bin bisher davon ausgegangen, dass das MVC meine Architektur vorgibt.
Ich hoffe nicht von mir?! :roll: Das Design oder die Architektur ist ein Zusammenspiel aus der Art und Weise, wie du deine Software - welche auch immer - aufbauen möchtest. Du kannst hier gerne auf Pattern zurückgreifen, musst das aber nicht. Sofern du Pattern verwendest, wird in einer Gesamt-Architektur immer die Kooperation - also das Zusammenwirken der Pattern - entscheidend sein, nicht ein einzelnes Pattern. Das ist auch für ein Pattern zuviel verlangt, es hat ja immer einen definierten Gültigkeitsbereich und einen Anwendungs-Fall für den es geschrieben wurde. Ein Pattern ist quasi die Lösung zu alltäglichen Problemen.

Ich hoffe der Pattern-Jungle wird nun etwas klarer! :)
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 21.09.2009, 00:19:20

Hi Doc,
dr.e. hat geschrieben:
Ich bin eher der Meinung, dass das vorgenommene Projekt um einiges zu hoch für mich ist :?
OK, dann lass uns das erst mal theoretisch klar kriegen.
besser wärs.. :?
dr.e. hat geschrieben:
Ich bin fühle mich ziemlich vor dem Kopf gestoßen, da ich mich auf die Aussagen der Framework-Entwickler verlassen habe. Was genau bildet denn dann die Architektur? Die kooperation aus allen Patterns? Bin bisher davon ausgegangen, dass das MVC meine Architektur vorgibt.
Ich hoffe nicht von mir?! :roll: Das Design oder die Architektur ist ein Zusammenspiel aus der Art und Weise, wie du deine Software - welche auch immer - aufbauen möchtest. Du kannst hier gerne auf Pattern zurückgreifen, musst das aber nicht. Sofern du Pattern verwendest, wird in einer Gesamt-Architektur immer die Kooperation - also das Zusammenwirken der Pattern - entscheidend sein, nicht ein einzelnes Pattern. Das ist auch für ein Pattern zuviel verlangt, es hat ja immer einen definierten Gültigkeitsbereich und einen Anwendungs-Fall für den es geschrieben wurde. Ein Pattern ist quasi die Lösung zu alltäglichen Problemen.


Ich hoffe der Pattern-Jungle wird nun etwas klarer! :)
Nein, nicht von dir. Eher von den anderen Framework-Entwickler, die wie du sagst, das MVC als "Kriegs-entscheidende Pattern verkaufen".


leider widerspricht das komplett meinem bisherigen Verständnis. Ich kenne das ja nur aus dem Zend Framework und der dazugehörigen Ordnerstruktur:
application
controllers
-> actions
models
->service
-> domänen Objekt
-> mapper
views
-> view
die Businesslogik ist dann entweder im Controller (fat controller/thin model) oder im Modell (thin controller / fat model).

Zum besseren Verständnis, wie ich das meine, einen Slide von Matthew Weier O'Phinney (Projektleiter vom ZF) http://www.slideshare.net/weierophinney ... ts-1766001 sowie einen Beitrag in seinem Blog "Modell Infrastruktur" http://weierophinney.net/matthew/archiv ... cture.html und einem Zitat einer Diskussion im zfforum: http://www.zfforum.de/showpost.php?p=38534 (man beachte auch die Grafik im Anhang)

Meinst du das genau so oder verstehe ich das Konzept falsch?

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Gästebuch Tutorial

Beitrag von dr.e. » 21.09.2009, 21:11:58

Hi Thalo,
leider widerspricht das komplett meinem bisherigen Verständnis. Ich kenne das ja nur aus dem Zend Framework und der dazugehörigen Ordnerstruktur:
[..]
die Businesslogik ist dann entweder im Controller (fat controller/thin model) oder im Modell (thin controller / fat model).
Das liegt meinem Verständnis nach an der Tatsache, dass das ZF das MVC-Pattern als "komplette Architektur" versteht und den Schwerpunkt auf die Strukturierung nach diesem legt. Dadurch kommt auch die Tatsache zu Stande, dass dem Model der Mapper und ein Business-Service zubemessen wird, das meiner - und da stimmen wir ja überein - Ansicht nach zu einer Überbewertung führt. MVC kann nicht eine komplette Architektur dominieren. Dies führt unweigerlich zur Überfrachtung des Models und bedeutet, dass du sämtliche Daten-Logik dort kapselst und nicht widerverwendbar ist.
Zum besseren Verständnis, wie ich das meine, einen Slide von Matthew Weier O'Phinney (Projektleiter vom ZF) http://www.slideshare.net/weierophinney ... ts-1766001 sowie einen Beitrag in seinem Blog "Modell Infrastruktur" http://weierophinney.net/matthew/archiv ... cture.html und einem Zitat einer Diskussion im zfforum: http://www.zfforum.de/showpost.php?p=38534 (man beachte auch die Grafik im Anhang)

Meinst du das genau so oder verstehe ich das Konzept falsch?
Matthew Weier O'Phinney ist meiner Ansicht nach überzeugt, dass es sinnvoll ist, zuerst ein Domänen-Model zu erstellen - der Blog-Eintrag sagt selbiges. Und genau das ist auch meine Philosophie. Die Anwendung steht und fällt mit den Daten, die eine Anwendung behandelt. Diese können im einfachsten Fall über ein Model abgebildet werden, müssen aber nicht. Üblicherweise ist eine Anwendung jedoch komplexer und benötigt Daten-Abstraktion. Die Grafik im ZF-Forum ziehlt genau auf die Architektur des ZF ab und ist mit den oben aufgezeigten Problemen behaftet.

Um dir noch etwas Lese-Stoff zu geben, habe ich dir eine PN mit zwei noch nicht veröffentlichten Artikel geschickt, diese helfen dir sicher, wenn es um den Entwurf einer Anwendung mit diesen Pattern geht.
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 27.09.2009, 20:22:20

Hi Doc,

Ich möchte das ganze mal zusammenfassen:
Das liegt meinem Verständnis nach an der Tatsache, dass das ZF das MVC-Pattern als "komplette Architektur" versteht und den Schwerpunkt auf die Strukturierung nach diesem legt.
Genau genommen ist die Bezeichnung "MVC-Framework" also falsch?

Die 3-Tier Architektur schreibt vor die Anwendung in die Schichten
  • Präsentationsschicht
  • Logikschicht
  • Datenschicht
zu unterteilen. Wobei das MVC ein Pattern der Präsentationsschicht ist, welches die Präsentationslogik ((Controller): User Events wie onclick), den Status der Anwendung ((Model): Benutzer hat xyz ausgewählt) und der eigentlichen Ausgabe, dem View, trennt? - Richtig? :D

Was mich etwas irritiert ist, dass das Model nach Trennung der Businessschicht zugeordnen wird. Handelt es sich dann nicht eher um ein VC in der Präsentationsschicht? Oder geht es nur um die eigentliche Trennung und weniger darum, welcher Schicht das schlussendlich zugeteilt wird?

Dies führt unweigerlich zur Überfrachtung des Models und bedeutet, dass du sämtliche Daten-Logik dort kapselst und nicht widerverwendbar ist.
Das ist mir auch nicht recht klar. Warum sind die Module nicht wiederverwendbar? Wie gezeigt, wird hier die selbe Abstraktion vorgenommen (Service Layer, Domänen Objekt, Data Mapper, ..) wie auch beim APF?
Das MVC-Pattern beschreibt die Trennung zwischen dem dargestellten Inhalt und der
Definition der Applikations-Workflows (Model), der Beschreibung der Darstellung und des
Aussehens der Applikation (View) und der eigentlichen Darstellungs-Logik (Controller).
Das ist mir ebenfalls nicht ganz klar. Meinst du mit "Definition der Applikations-Workflows (Model)" den aktuellen Status der Anwendung?



Ferner ist mir noch nicht ganz klar, gibt es gar keine "Actions" in den Controllern, so wie beim Zend Framework?

Benutzeravatar
dr.e.
Administrator
Beiträge: 4555
Registriert: 04.11.2007, 16:13:53

Re: Gästebuch Tutorial

Beitrag von dr.e. » 27.09.2009, 20:52:53

Hi Thalo,
Genau genommen ist die Bezeichnung "MVC-Framework" also falsch?
Das hat schon seine Richtigkeit, den die Frameworks bauen ja auf dem MVC-Pattern auf. Es bleibt jedoch bei der angesprochenen Problematik mit der Bewertung von MVC. Das Zend Framework ist eigentlich kein "echtes" Framework - genau wie eZ Components - sondern eine Klassen-Bibliothek. Grund hierfür ist, dass keine so enge Verzahnung der Komponenten vorhanden ist und die Bibliotheken keinen Weg vorzeichnen, wie Software zu implementieren ist.
Wobei das MVC ein Pattern der Präsentationsschicht ist, welches die Präsentationslogik ((Controller): User Events wie onclick), den Status der Anwendung ((Model): Benutzer hat xyz ausgewählt) und der eigentlichen Ausgabe, dem View, trennt? - Richtig? :D
Völlig korrekt!
Was mich etwas irritiert ist, dass das Model nach Trennung der Businessschicht zugeordnen wird. Handelt es sich dann nicht eher um ein VC in der Präsentationsschicht? Oder geht es nur um die eigentliche Trennung und weniger darum, welcher Schicht das schlussendlich zugeteilt wird?
Es geht bei der Kooperation von Pattern - in diesem Fall 3-Schicht-Architektur + MVC - zunächst um eine sinnvolle Ergänzung der beiden Pattern. In manchen Fällen kann es sinnvoll sein, das Model der Business-Schicht zuzuordnen, in anderen Fällen ist es besser in der Pres aufgehoben, weil es ausschließlich Informationen für diese Schicht hält. Dieser Punkt ist mehr oder weniger frei gestaltbar, ich schreibe das Model normal der Biz zu.
Das ist mir auch nicht recht klar. Warum sind die Module nicht wiederverwendbar? Wie gezeigt, wird hier die selbe Abstraktion vorgenommen (Service Layer, Domänen Objekt, Data Mapper, ..) wie auch beim APF?
Der Hintergrund ist folgender: in einer Kooperation von 3-Schicht-Architektur und MVC tritt das Model des MVC-Pattern zu Gunsten der Business-Schicht in den Hintergrund, da die Business-Schicht die Steuerung der Anwendung übernimmt. Aufgabe dieser ist es dann ebenfalls, sich um Datenbeschaffung und Persistierung zu kümmern. In einer etwas komplexeren Software werden oft mehrere Business-Komponenten - eine für jeden Bereich - implementiert. Diese Funktionen in ein Model zu packen bedeutet, dass das Model dermaßen viel Funktionalität beinhaltet, die nicht eben mal so in einer anderen Software wiederverwendet werden kann. Beispiel: du schreibst eine komplett auf MVC basierendes Benutzer-Management. Möchte ich dieses nun als Basis für meine Anwendung benutzen, bin ich gezwungen, das Model einer anderen Anwendung mit all seinen Abhängigkeiten zu benutzen, obwohl ich vielleicht nur eine Funktion brauche. Meiner Ansicht nach kann die Abstraktion in einem Model nie so gut sein, wie die Abstraktion in "echte" einzelne Komponenten wie einem DataMapper, einer Business-Schicht und einem "einfachen" Model, das sich um die eigentlichen Aufgaben (Darstellung) kümmert - weil das MVC-Pattern ja eine Verfeinerung des 3-Schicht-Pattern ist.

Sicher kannst du auch mit dem Zend Framework eine Abstraktion der beschriebenen Art erreichen, du musst dich jedoch immer ein Stück weit vom Gedanken lösen, dass das MVC das zentrale Architektur-Muster ist. Bei CakePHP & Co. ist das sogar noch schwieriger, weil du keine wirkliche Unterstützung für eine eigene Implementierung von DataMapper etc. hast.

Das wichtigste ist deshalb, das Bewusstsein zu haben, dass MVC nur eine Verfeinerung der 3-Schicht-Architektur ist und das Model deshalb nicht als "Business- und Daten-Schicht und Datenbank-Abstraktion in einem" betrachtet werden darf. Das Model sollte auch tunlichst nicht die Datenstruktur kennen, sonst gerätst du schnell in die Verlegenheit, dass eine Änderung deiner Datenstruktur - die ja umfangreicher sein kann, also du es in der konkreten Anwendung grade brauchst - eine diekte Änderung deines Models betrifft.
Das ist mir ebenfalls nicht ganz klar. Meinst du mit "Definition der Applikations-Workflows (Model)" den aktuellen Status der Anwendung?
Genau. Das Model in einer 3-Schicht-Architektur + MVC ist üblicherweise mehr für die Repräsentation des Anwendungs-Status zuständig, denn für die Daten-Acquise. In einem "echten" Workflow (z.B. Shop-Bestellung) wäre das: Wo befindet sich der Kunde grade? Was hat er im Warenkorb? Wie möchte er zahlen? ...
Ferner ist mir noch nicht ganz klar, gibt es gar keine "Actions" in den Controllern, so wie beim Zend Framework?
Das Konzept des APF geht einen deutlichen Schritt weiter wie die Actions im ZF. Das Herzstück des Applikations-Frameworks bildet der Page-Controller. Seine Funktion besteht darin, Anfragen entgegen zu nehmen und einen allgemeingültigen Rahmen für Applikationen zu bieten, die nach dem HMVC-Muster erstellt werden. Er verfügt daher über Mechanismen zum Laden und Verarbeiten von Templates mit Hilfe der Funktionen von Taglibs, zur Ausführung von (MVC-)Controllern und zum Handling des HMVC-DOM-Baumes, der mit Hilfe der Taglibs erzeugt wird.
Da der Page-Controller selbst einen Funktions-Rahmen bereitstellt, kann die Applikations-Logik durch eigene Taglibs und (MVC-)Controller direkt vom Entwickler beeinflusst werden. Die Komponente selbst handelt dabei unabhängig von der in Taglibs definierter Logik. Auf diese Weise ist es möglich, Tags mit sehr unterschiedlichen Funktionen wie beispielsweise Platzhalter oder Formulare zu erstellen.
Der Front-Controller ist eine Erweiterung des Page-Controllers, der vor dem Erstellen der Seite, nach dem Aufbau des DOM-Baumes und nach der Transformation so genannte Actions ausführt. Diese können für verschiedene Aufgaben innerhalb einer Applikation wie beispielsweise das Befüllen eines Models eingesetzt werden.

Damit hast du beim APF die Möglichkeit, dein Applikation mit drei Arten von Controllern/Actions aufzubauen. Du bist also erstens flexibler und wirst zweitens besser unterstützt, deine Applikation granularer aufzubauen. Nichts ist schlimmer, als die komplette Logik einer Webseite in eine Controller-Klasse quetschen zu müssen.
Viele Grüße,
Christian

Thalo
Beiträge: 247
Registriert: 10.08.2009, 16:56:52

Re: Gästebuch Tutorial

Beitrag von Thalo » 27.09.2009, 23:16:30

Hi Doc,

Puuh, komplizierte Sache das ganze.. :geek:

Wenn man Zend Objektiv betrachtet, frage ich mich, warum so viele Zend einsetzen?
Es geht bei der Kooperation von Pattern - in diesem Fall 3-Schicht-Architektur + MVC - zunächst um eine sinnvolle Ergänzung der beiden Pattern. In manchen Fällen kann es sinnvoll sein, das Model der Business-Schicht zuzuordnen, in anderen Fällen ist es besser in der Pres aufgehoben, weil es ausschließlich Informationen für diese Schicht hält. Dieser Punkt ist mehr oder weniger frei gestaltbar, ich schreibe das Model normal der Biz zu.
Zum Verständnis für mich:
Nutze ich ein Model, was ich ausschließlich in der Präsentation verwende (Boxen sind aus oder aufgeklappt, Button ist geklickt, ..) weise ich dies der Präsentationsschicht zu. Nutze ich aber ein Model was ich zum Austausch verschiedener Schichten benutze (z.B das Domänen Objekt) dann der Business? Oder werfe ich da gerade etwas durcheinander? :D
Das wichtigste ist deshalb, das Bewusstsein zu haben, dass MVC nur eine Verfeinerung der 3-Schicht-Architektur ist und das Model deshalb nicht als "Business- und Daten-Schicht und Datenbank-Abstraktion in einem" betrachtet werden darf.
Das hat mich schon von Anfang an an Zend gestört. Das entsprach nie meiner Interpretation eines Models. Nun ist das klarer geworden. ;)

Ich habe mir den Artikel AJAX & the APF angesehen. Ist die Ausgabe der XML nicht die Aufgabe des Views?


Ist es nicht möglich, mit dem mailSender des APFs, eine eigene SMTP Socket zu öffnen? Grund hierfür ist: mail öffnet für jede Mail einen neuen Socket, was bei großer Anzahl an Mails (Errinerungen, Newsletter, ...) nicht wirklich günstig ist.


Mir ist auch nicht klar, warum in der PHP5-Version des APFs immer noch auf trigger_error anstatt auf Exceptions zurückgegriffen wird? Ebenfalls, warum du so häufig Referenzen benutzt? ( wegen dem "Bug" aus PHP4, dass Objekte als Kopie und nicht als Referenz übergeben wurden?)


Ganz schön viele Fragen :D

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast