bitsnack

Hallo,

Ich "streite" mich mit jemandem darüber was HMVC jetzt eigentlich ist:

Meine Ansicht:
Ein Controller A lädt einen anderen Controller B(z.B. über Request::execute('b')) welcher durch Models und Views eine Ausgabe generiert welche nicht ausgegeben sondern an den Controller A zurückgegeben wird und dort weiterverwendet werden kann, z.B. in eine View als Navigation eingesetzt werden kann wobei diese gesamte Navigation eben durch Controller B generiert wurde.

Seine Ansicht:
Laut seiner Beschreibung glaube ich zu wissen dass er meint dass meine Interpretation von HMVC noch nicht vollständig ist, sondern auch die Klassenhirarchie dazu gehört, also dass es eben eine Controller oder Model Klasse gibt von der alle anderen Controller- oder Model-Klassen abstammen. (mit B extends A, dann vlt. C extends B usw) was meinet Meinung nach schon zu einem gescheiten Aufbau gehört, aber nicht explizit etwas mit HMVC zu tun hat.

Was ist jetzt korrekt?

Vielen dank im Voraus.

greez

bitsnack

Mister Ad

xm22

Das hat direkt mit hmvc rein gar nichts zu tun...

dr.e.

Hallo bitsnack,

ihr sprecht von unterschiedlichen Dingen. HMVC ist konzeptionell ein Baum von Elementen, die für sich genommen alle das MVC-Pattern implementieren. Dass alle Baum-Elemente von einem gemeinsamen Über-Element abstammen müssen, beschreibt das Composite Pattern. Beide können bei einer Implementierung von HMVC Anwendung finden, müssen sie aber nicht. Fakt ist jedoch, dass HMVC nicht heißt, dass der Baum von MVC-Elementen der Vererbungs-Hierarchie entsprechen müssen - auch nicht in Teilen!

An der Implementierung des HMVC-Pattern des APF sind mehrere Komponenten beteiligt:

• Page-Controller
• Page (Root-Element des Baums)
• Document (Klasse, von der alle Baum-Elemente ableiten, jedoch nicht in einer direkten Hierarchie-Parallele zum Baum)
• Controller (der jeweilige MVC-Controller zum Baum-Element, das durch eine Instanz von Document oder seiner Unterklassen repräsentiert werden)
• Model (eine Model-Instanz; oft auch ein View-Model in Kombination mit einem Service zur Kapselung des Datenzugriff)
• Templates (View-Komponente; nahezu gleich zu setzen mit dem aktuellen Baum-Knoten)

Die Idee, über Controller eine Hierarchie und Abhängigkeit aufzubauen, wie du sie beschreibst, ist jedoch an der Flexibilität von HMVC ebenso vorbei. Hier gab es bereits einen Thread, der die Nachteile einer solchen Implementierung dargelegt hat. HMVC ermöglicht zwar, Ergebnisse von tieferen Strukturen in höheren Ebenen zu verwenden, dies sollte jedoch auf eine Art und Weise passieren, die keine expliziten Abhängigkeiten im Quellcode generiert (Stichwort: loose coupling).

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

bitsnack

Was ist dann die korrekte Beschreibung von HMVC?

nikosch

Laut http://en.wikipedia.org/wiki/Present...action-control ein PAC Pattern mit loser Komponentenbindung.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

bitsnack

Gut, genauso bzw. so ähnlich meinte ich das auch, diverse Texte die ich jetzt über HMVC gelesen habe bestätigen das auch. Jetzt hoffe ich nur noch dass er es nicht genau gleich meinte und ich es einfach falsch verstanden habe.

Vielen Dank!

xm22

..., der leider nicht zu Ende diskutiert worden ist..

dr.e.

Aus meiner Sicht kann man nicht mehr Gründe zu diesem Thema darlegen. Insofern ist die Diskussion für mich beendet, da sie weiter zu führen weder fruchtbar noch sinnvoll ist.

__________________
Viele Grüße,
Dr.E.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design before you start to write code!
2. Discuss and review it together with experts!
3. Choose good tools (-> Adventure PHP Framework (APF))!
4. Write clean and reusable software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~