xm22

Das ist ein Objekt, dass diverse Dinge zur Verfügung stellt (Request, Response, Authentifizierung, ACL und eben auch hmvc-Funktionalität).

Mister Ad

nikosch

EIN Objekt tut dies alles? Warum denn das?

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

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

dr.e.

Wie ich uncle bob nicht ausstehen kann!

__________________
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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

xm22

Was ist denn "das alles"? Es macht sogar noch mehr, aber das ist nebensächlich.
Habe ich was nicht mit bekommen?

nikosch

ucle bob ist auch als „GOD object“ oder „Big hairy object“ bekannt.

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

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

xm22

Ok - Wo würdet ihr denn diese Objekte hin packen? DI, nehme ich mal an. Und vielleicht ist ja das App-Objekt genau dieses..

fab

God Class

So sieht der Code aber nicht aus. Und du schreibst, es stellt Funktionalität zur Verfügung. Ein DI Container hat selber eigentlich keine Funktionalität und arbeitet relativ still im Hintergrund oder nicht?

__________________
PHP Blog + Library
CSS Effects + Tools

nikosch

Also, aus Deinem Satz
habe ich herausgelesen, dass Du Request, Response ... alles in einem Objekt kapselst. Meinst Du etwa eine Registry?

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

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

dr.e.

Hallo xm22,

sei mir nicht böse, aber ich konnte mir "uncle bob" (~=god object) nicht verkneifen. Das ist genau die Form von Abstraktion, von der ich in meinen Posts nicht sprach. Wenn du eine Registry haben möchtest - aus welchen Gründen auch immer - dann soll das auch namentlich eine solche sein. Möchtest du Request und Response abstrahieren, was ich persönlich für einen Blödsinn halte, da es keinen Mehrwert gegenüber den in PHP vorhandenen Mechanismen bringt, dann bitte nicht alles in einem Objekt.

An der von dir zitierten Stelle möchtest du ein HMVC-Modul einklinken. Dazu braucht es ein Rahmenwerk über das du dieses tun kannst - eine Art Container. Diesem werden per DI die relevanten Informationen mitgegeben und in diesem wird es ausgeführt. Das sind jedoch Komponenten, über die wir hier sprechen, die nichts mit einem App-Objekt zu tun haben, sondern im Sinne eines OO-Design eigenständig modelliert werden müssen. Du kaufst ja einen Weber-Grill auch nicht im Klamotten-Laden.

Ich würde dir deshalb empfehlen, nicht krampfhaft am HMVC-Ansatz zu schrauben, damit du hinterher etwas fertiges vorzuweisen hast, sondern zu versuchen, das Ganze zunächst zu modellieren um die klar zu werden, an welchen Stellen du was überhaupt benötigst. Stell dir Fragen wie

• Wie ist ein Baum aufgebaut?
• Welche Mechanismen braucht der Entwickler für eine Moduarisierung?
• Welche Services müssen zur Verfügung gestellt werden, damit ein Modul arbeiten kann?
• Welche Abhängigkeiten sind notwendig, welche sollten vermieden werden?
• Wie ist das Timing-Modell der Baum-Verwaltung und wo muss ein Entwickler eingreifen können um bestimmte Verhalten realisieren zu können?
• Was bedeutet das MVC-Pattern innerhalb eines MVC-Baumes?
• Welche Anforderungen hat ein Entwickler an die MVC-API, bzw. wie soll sich ein Controller realisieren lassen?

Erst dann ist es sinnvoll die Implementierung zu starten.

__________________
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!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

xm22

Nein - Das sind alles eigenständige Objekte.

Wenn ich mir überlege, dass die Applikation vielleicht auch per Console aufgerufen werden könnte, oder die Response sonstwie automatisiert werden sollte, finde ich schon, dass das eine gute Idee ist. Auch ein separates Request-Objekt halte ich persönlich für erforderlich. In meinem Framework übernimmt dieses auch Teile des Front-Controllers und die Erstellung von URLs.

Das Ganze ist seit mittlerweile 3 Jahren gereift. Es sind dabei alle Anforderungen beachtet wurden, die sich aus mehrjähriger Erfahrung ergeben haben - Dazu gehört auch die Effizienz beim Umsetzen von Applikationen. Mag sein, dass ich nicht allen Paradigmen der Software-Entwicklung entspreche, aber bei mir hat Produktivität Vorang vor Theorien - Damit meine ich allerdings nicht, dass ich Frickeleien und Hacks bervorzuge - Im Gegenteil. Ich versuche auch nicht, krampfhaft an etwas festzuhalten, sondern dieser Ansatz hat sich als der beste herausgestellt.

Die Diskussion geht hier jetzt in Richtung eines Aspektes des Frameworks - Mein Post sollte nur zeigen, wie effizient das Einbinden einesw HMVC-Knoten sein kann ohne GUI-Strukturen zu nutzen.