Struktur mit Framework, Fragen

Das Forum soll der Ablage von Lösungen für immer wieder auftauchende Problemstellungen dienen. // This forum contains solutions to problems that frequently occur.
Antworten
dirtdevel
Beiträge: 28
Registriert: 26.12.2011, 23:51:51

Struktur mit Framework, Fragen

Beitrag von dirtdevel » 27.12.2011, 00:07:42

Hallo,
ich beherrsche PHP Grundlagen und bin gerade dabei mich in Softwarestrukturierung, Design Patterns usw. vertraut zu machen.

Da ich noch etwas unsicher mit der Materie bin (Arbeite gerade das Buch "PHP Design Patterns" von O'Reilly durch), wollte ich einige Fragen stellen.

Eine Software basiert aus Präsentationsschicht (HMVC), Logik-/Businessschicht und Persistenzsschicht (Datenbank).

1. Wo platziert sich das Adventure-PHP-Framework in der gesamten Struktur?
2. Wie sieht die Verbindung zwischen Model und Businessschicht aus? (Kenne das nur, dass der Model Daten aus der Datenbank holt)

Hoffe jemand ist willig auch solche Fragen zu antworten und hoffe, ich habe das richtige Unterforum erwischt ;)

Gruß,
dirtdevel

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

Re: Struktur mit Framework, Fragen

Beitrag von dr.e. » 27.12.2011, 14:06:06

Hallo dirtdevel & herzlich willkommen im APF-Forum! :geek:
Hoffe jemand ist willig auch solche Fragen zu antworten und hoffe, ich habe das richtige Unterforum erwischt ;)
Natürlich beantworten wir/beantworte ich deine Fragen.
Eine Software basiert aus Präsentationsschicht (HMVC), Logik-/Businessschicht und Persistenzsschicht (Datenbank).
Du zitierst hier das "3-tier-pattern", das besagt, dass eine Applikation in drei Schichten geteilt werden soll um beispielsweise Wartbarkeit und Austauschbarkeit von Schichten zu verbessern bzw. überhaut erst zu ermöglichen.
1. Wo platziert sich das Adventure-PHP-Framework in der gesamten Struktur?
Das APF platziert sich im Grunde als ein Tool, das dich in allen drei Schichten unterstützt. Dabei ist die Ausprägung der Unterstützung jeweils pro Schicht etwas unterschiedlich, da ein Framework nur dort perfekt unterstützen kann, wo es generische Aufgaben gibt. Beispiel:
  • Präsentationsschicht: hier gibt es den Front- und Page-Controller zur Steuerung der Request-Verarbeitung und als allgemeingültige HMVC-Implementierung. Diese unterstützen dich sehr stark beim Erstellen von GUI-Strukturen, deren Kapselung und Kombination. Führendes Beispiel ist hier die Formular-Unterstützung basierend auf dem HMVC-Ansatz.
  • Businessschicht: hier ist die Unterstützung dünner gesäht, das Business-Logik immer ein konkretes Domänen-Problem darstellt für das es - logischerweise - keine Standard-Lösung geben kann. Trotzdem besitzt das APF Mechanismen, die dich hierbei unterstützen können: einen DI-Container und convenience-Methoden in der Objektdefinition, mit denen du sehr einfach einen Service in der Präsentationsschicht beziehen kannst.
  • Datenschicht: hier gibt es den GORM als starkes Tool für das Datenhaltungsmanagement. Dieser kann beliebige Objekte und deren Beziehungen verwalten und besitzt ein Management-Tool, das die Datenbank-Tabellen automatisiert verwalten kann.
Daneben bietet das APF einige Hilfsmittel als Querschnittsfunktionen an. Beispiele: Benchmarker, zentrales Fehler- und Exception-Handling, Url-Abstraktion und Link-Generierung, Input- und Outputfilter sowie viele Weitere (siehe z.B. http://adventure-php-framework.org/Seit ... umentation)
2. Wie sieht die Verbindung zwischen Model und Businessschicht aus? (Kenne das nur, dass der Model Daten aus der Datenbank holt)
Im MVC-Bereich ist das Model oft die Brücke zwischen Persistenz und Präsentation, es gibt jedoch im HMVC-Bereich weitere Interpretationen.
Bleiben wir bei MVC, so stellt das Model die Entitäten einer Anwendung dar, die i.d.R. sehr einfach und eindimensional sind. Eine News-Verwaltung kennt beispielsweise lediglich ein Model: "News". Hier kannst du das Model News nennen und es im Rahmen des table data gateway- oder row data gateway-Pattern direkt mit der Verwaltung der Daten betrauen. Dies ist jedoch nur in seltenen Fällen sinnig, da CRUD-Aufgaben (zumeist) sehr einfach abstrahiert werden können und dadurch (aus Sicht des Models) eine Delegation des Mechanismus an eine eigene Komponente die bessere Lösung ist. Üblicherweise - so sagen die meisten Interpretation des 3-tier-architecture-pattern - ist das Model des MVC-Pattern Teil der Präsentationsschicht und damit ist die Delegation der Persistenz an eine entsprechende Komponente - aus diesem Blickwinkel betrachtet - ebenfalls die bessere Lösung. Hier ist jedoch das Model immer eine - wie oben angedeutet - sehr kleine, eindimensionale Einheit.
Sprechen wir von komplexeren Anwendungen, so ist ein Model sicher nicht ausreichend. In einer Web-Anwendung zur Verwaltung von Benutzern gibt es mehrere Entitäten und deren Beziehungen, die das Datenmodell ausmachen. Hier ist es dann wiederum intelligenter auf entweder das domain-object-pattern oder das transaction-script-pattern in Verbindung mit eigenen DTOs für die Objekte zu setzen. In diesem Fall ist dann das Domänen-Modell Teil der Business-Schicht und wird entweder von einer eigenen, generischen Datenhaltungskomponente unterstützt (delegate; domain-object-pattern) oder einem dafür implementierten Mapper zwischen Objekt und relationaler Datenhaltung transformiert (usage; für transaction-script-pattern in Verbindung mit eigenen DTOs). Beide Modelle haben ihre Vor- und Nachteile, das domain-object-pattern ist in Summe etwas schwieriger zu implementieren, da die Modellierung nicht so einfach ist.

Beantwortet das deine Frage? Falls nicht, gehe ich gerne nochmal auf konkrete Details ein.
Viele Grüße,
Christian

dirtdevel
Beiträge: 28
Registriert: 26.12.2011, 23:51:51

Re: Struktur mit Framework, Fragen

Beitrag von dirtdevel » 27.12.2011, 15:17:34

Hallo dirtdevel & herzlich willkommen im APF-Forum!
Danke für die Begrüßung ;)
Du zitierst hier das "3-tier-pattern", das besagt, dass eine Applikation in drei Schichten geteilt werden soll um beispielsweise Wartbarkeit und Austauschbarkeit von Schichten zu verbessern bzw. überhaut erst zu ermöglichen.
Gibt es weitere (bessere?) Patterns?
Das APF platziert sich im Grunde als ein Tool, das dich in allen drei Schichten unterstützt. Dabei ist die Ausprägung der Unterstützung jeweils pro Schicht etwas unterschiedlich, da ein Framework nur dort perfekt unterstützen kann, wo es generische Aufgaben gibt. Beispiel:
APF nimmt mir also die Arbeit grundlegende Funktionen/Prozesse (insbesondere Präsentationsschicht, Datenspeicherung, sowie oft auftretende Anwendungen (Validierungen) ab. Ich muss die einzelnen Werkzeuge mehr oder weniger zusammenfügen, erweitern insbesondere die Geschäftslogik, welche dann ans Framework anschließt.
Im MVC-Bereich ist das Model oft die Brücke zwischen Persistenz und Präsentation, es gibt jedoch im HMVC-Bereich weitere Interpretationen.
Dazu habe ich nochmal eine Zwischenfrage. Das MVC Prinzip verstehe ich, bei dem HMVC bin ich nicht sicher, ob ich es verstehe :)
Ich interpretiere das HMVC folgendermaßen:
Ich habe eine Seite, welche sich aus verschiedenen hierarchischen Bereichen zusammensetzt (Forum, Blog) oder einfach nur eine Seite, welche hierarchiel aufgebaut ist (News->2010->August). Dies wird dann mit dem HMVC Prinzip gelöst, sodass es ein eigenes MVC für jeden dieser Bereiche gibt.
So übernimmt ein eigener Controller den Blog usw. Vermutlich wird es allerdings in der Praxis so sein, dass es nicht einen extra Controller gibt, sondern das dieser in gewisser weise Rekursiv mit spezielleren Parametern ausgeführt wird?
Geht diese Interpretation in die richtige Richtung oder liege ich komplett falsch?
Im MVC-Bereich ist das Model oft die Brücke zwischen Persistenz und Präsentation, es gibt jedoch im HMVC-Bereich weitere Interpretationen.
Bleiben wir bei MVC, so stellt das Model die Entitäten einer Anwendung dar, die i.d.R. sehr einfach und eindimensional sind. Eine News-Verwaltung kennt beispielsweise lediglich ein Model: "News". Hier kannst du das Model News nennen und es im Rahmen des table data gateway- oder row data gateway-Pattern direkt mit der Verwaltung der Daten betrauen. Dies ist jedoch nur in seltenen Fällen sinnig, da CRUD-Aufgaben (zumeist) sehr einfach abstrahiert werden können und dadurch (aus Sicht des Models) eine Delegation des Mechanismus an eine eigene Komponente die bessere Lösung ist. Üblicherweise - so sagen die meisten Interpretation des 3-tier-architecture-pattern - ist das Model des MVC-Pattern Teil der Präsentationsschicht und damit ist die Delegation der Persistenz an eine entsprechende Komponente - aus diesem Blickwinkel betrachtet - ebenfalls die bessere Lösung. Hier ist jedoch das Model immer eine - wie oben angedeutet - sehr kleine, eindimensionale Einheit.
Sprechen wir von komplexeren Anwendungen, so ist ein Model sicher nicht ausreichend. In einer Web-Anwendung zur Verwaltung von Benutzern gibt es mehrere Entitäten und deren Beziehungen, die das Datenmodell ausmachen. Hier ist es dann wiederum intelligenter auf entweder das domain-object-pattern oder das transaction-script-pattern in Verbindung mit eigenen DTOs für die Objekte zu setzen. In diesem Fall ist dann das Domänen-Modell Teil der Business-Schicht und wird entweder von einer eigenen, generischen Datenhaltungskomponente unterstützt (delegate; domain-object-pattern) oder einem dafür implementierten Mapper zwischen Objekt und relationaler Datenhaltung transformiert (usage; für transaction-script-pattern in Verbindung mit eigenen DTOs). Beide Modelle haben ihre Vor- und Nachteile, das domain-object-pattern ist in Summe etwas schwieriger zu implementieren, da die Modellierung nicht so einfach ist.
Das sind erstmal viele Informationen :)
Leider bin ich noch nicht sehr mit den Enterprise Patterns vertraut, weswegen ich nur grob was dazu sagen kann.
Aber meine Hauptfrage ist damit beantwortet: Ich kann meine Geschäftslogik bzw. die Persistenzschicht beliebig an das APF schnüren.

Gruß,
dirtdevel

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

Re: Struktur mit Framework, Fragen

Beitrag von dr.e. » 27.12.2011, 18:44:21

Hallo dirtdevil,
Gibt es weitere (bessere?) Patterns?
Es gibt viele weitere Patterns. 8-) Allerdings bist du mit MVC und 3-tier-architecture schon sehr gut beraten. Implizit "zwingt" dich das APF ja bereits unbewusst einige Pattern einzusetzen. Ich würde daher nicht krampfhaft nach neuen Pattern suchen, sondern zunächst die beiden anwenden.

Jedes Pattern hat seinen speziellen Anwendungsfall und seine definierten Rahmenbedingungen, insofern eignet sich nicht jedes Pattern für jeden Anwendunsfall.
APF nimmt mir also die Arbeit grundlegende Funktionen/Prozesse (insbesondere Präsentationsschicht, Datenspeicherung, sowie oft auftretende Anwendungen (Validierungen) ab. Ich muss die einzelnen Werkzeuge mehr oder weniger zusammenfügen, erweitern insbesondere die Geschäftslogik, welche dann ans Framework anschließt.
Korrekt. Sofern du bereits bestehende Komponenten hast, kannst du diese natürlich integrieren.
So übernimmt ein eigener Controller den Blog usw. Vermutlich wird es allerdings in der Praxis so sein, dass es nicht einen extra Controller gibt, sondern das dieser in gewisser weise Rekursiv mit spezielleren Parametern ausgeführt wird?
Geht diese Interpretation in die richtige Richtung oder liege ich komplett falsch?
HMVC ist eine Erweiterung von MVC zu einer hierarchischen, Baum-artigen Struktur. Diese findet nicht hinsichtlich der Webseiten-Struktur (=Sitemap) sondern auf einer einzelnen Seite (z.B. Startseite) Anwendung. Du kannst damit jedes Modul bzw. jede Komponente deiner Seite (z.B. Content-Bereich, News-Teaser, Navigation, ...) als eigene MVC-Komponenten formulieren und z.B. auf der Startseite als Baum von mehreren MVC-Elementen zusammenfügen. Wenn du dir mal die Benchmark-Ausgabe ansiehst, kannst du die unterschiedlichen Hierarchien an Hand der Einrückungen erkennen. Zugegeben, die Darstellung ist mit dem Stylesheets nicht optimal, aber erkennbar.

Beantwortet das deine Frage?
Leider bin ich noch nicht sehr mit den Enterprise Patterns vertraut, weswegen ich nur grob was dazu sagen kann.
Kein Problem. Das APF unterstützt dich bereits unbewusst hinsichtlich der Verwendung von Pattern.
Aber meine Hauptfrage ist damit beantwortet: Ich kann meine Geschäftslogik bzw. die Persistenzschicht beliebig an das APF schnüren.
Korrekt. :)

Solltest du weitere Fragen haben, melde dich einfach.
Viele Grüße,
Christian

dirtdevel
Beiträge: 28
Registriert: 26.12.2011, 23:51:51

Re: Struktur mit Framework, Fragen

Beitrag von dirtdevel » 27.12.2011, 20:30:56

Danke für die guten Support ;)
HMVC ist eine Erweiterung von MVC zu einer hierarchischen, Baum-artigen Struktur. Diese findet nicht hinsichtlich der Webseiten-Struktur (=Sitemap) sondern auf einer einzelnen Seite (z.B. Startseite) Anwendung. Du kannst damit jedes Modul bzw. jede Komponente deiner Seite (z.B. Content-Bereich, News-Teaser, Navigation, ...) als eigene MVC-Komponenten formulieren und z.B. auf der Startseite als Baum von mehreren MVC-Elementen zusammenfügen. Wenn du dir mal die Benchmark-Ausgabe ansiehst, kannst du die unterschiedlichen Hierarchien an Hand der Einrückungen erkennen. Zugegeben, die Darstellung ist mit dem Stylesheets nicht optimal, aber erkennbar.
Das verstehe ich noch nicht ganz.
Das HMVC basiert darauf, dass jedes Teilstück einer Webseite eigenständig von einem eigenen MVC generiert wird, aber wo liegt da der Vorteil?

Gruß,
dirtdevel

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

Re: Struktur mit Framework, Fragen

Beitrag von dr.e. » 27.12.2011, 21:38:05

Hallo dirtdevel,
Das HMVC basiert darauf, dass jedes Teilstück einer Webseite eigenständig von einem eigenen MVC generiert wird, aber wo liegt da der Vorteil?
Korrekt, das ist die Idee hinter HMVC. Vorteile:
  • Umständliche Konstrukte wie Layout-Handling oder View-Helper für die Auslagerung von entfallen.
  • Einzelne Software-Teile können gemäß ihrer Anwendung und Bedeutung verfasst und mit anderen beliebig kombiniert werden.
Weiterhin kannst du Dinge wie Formulare oder Iteratoren sehr einfach mit einer HMVC-Struktur implementieren und dadurch Funktionalität hinsichtlich Wiederverwendung ideal kapseln.
Viele Grüße,
Christian

dirtdevel
Beiträge: 28
Registriert: 26.12.2011, 23:51:51

Re: Struktur mit Framework, Fragen

Beitrag von dirtdevel » 27.12.2011, 22:10:25

Korrekt, das ist die Idee hinter HMVC. Vorteile:
Umständliche Konstrukte wie Layout-Handling oder View-Helper für die Auslagerung von entfallen.
Einzelne Software-Teile können gemäß ihrer Anwendung und Bedeutung verfasst und mit anderen beliebig kombiniert werden.
Weiterhin kannst du Dinge wie Formulare oder Iteratoren sehr einfach mit einer HMVC-Struktur implementieren und dadurch Funktionalität hinsichtlich Wiederverwendung ideal kapseln.
Gut, danke :)

Was ich mich jetzt noch frage: Was hat das mit einer Hierarchie zu tun?

Gruß,
dirtdevel

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

Re: Struktur mit Framework, Fragen

Beitrag von dr.e. » 27.12.2011, 22:27:10

Hi dirtdevel,

einen guten Vergleich bietet das Zend Framework. Dort wird eine Webseite oder eine Applikation mit Hilfe einer Zend_Layout-Komponente aufgebaut. In Summe hast du damit 2 Ebenen zur Strukturierung deiner Anwendung zur Verfügung: das Grundgerüst und die konkreten Bestandteile. Ist ein konkreter Bestandteil deiner Software komplexer und benötigt daher mehrere Ebenen (z.B. ein Haupt-Template mit Sub-Templates für Navigation, Inhalt und Footer), so bist du ohne HMVC und mit einer Layout-Komponente im Design deiner Software sehr eingeschränkt.
Viele Grüße,
Christian

dirtdevel
Beiträge: 28
Registriert: 26.12.2011, 23:51:51

Re: Struktur mit Framework, Fragen

Beitrag von dirtdevel » 28.12.2011, 01:29:31

Hi Christian,
einen guten Vergleich bietet das Zend Framework. Dort wird eine Webseite oder eine Applikation mit Hilfe einer Zend_Layout-Komponente aufgebaut. In Summe hast du damit 2 Ebenen zur Strukturierung deiner Anwendung zur Verfügung: das Grundgerüst und die konkreten Bestandteile. Ist ein konkreter Bestandteil deiner Software komplexer und benötigt daher mehrere Ebenen (z.B. ein Haupt-Template mit Sub-Templates für Navigation, Inhalt und Footer), so bist du ohne HMVC und mit einer Layout-Komponente im Design deiner Software sehr eingeschränkt.
Könntest du das mit den Haupt- und Sub-Templates nochmal genauer erläutern?

Bis auf der besseren Strukturierung, Gliederung durch die Spezialisierung und Einteilung verschiedener Ebene hat das HMVC keine weiteren Vorteile?

Gruß,
dirtdevel

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

Re: Struktur mit Framework, Fragen

Beitrag von dr.e. » 28.12.2011, 15:50:43

Hallo dirtdevil,
Könntest du das mit den Haupt- und Sub-Templates nochmal genauer erläutern?
HMVC bietet dir die absolute Freiheit in der Strukturierung deiner Templates. Das bedeutet, dass du nicht auf die Ebenen Layout und Komponente eingeschränkt bist, sondern die Struktur deiner Seite frei definieren kannst. Dies ist insbesondere dann wichtig, wenn du Komponenten baust, die in verschiedenen Projekten erneut zum Einsatz kommen sollen und du innerhalb dieser Komponten ebenfalls die Freiheit genießen möchtest sie nach den gestellten Anforderungen und nach allen Regeln der Kunst zu strukturieren.

Nehmen wir an, du erstellst eine Webseite mit einem Header, einem Inhaltsbereich und einem Footer (=Ebene 1). Diese stellen den groben Rahmen der Seite dar. Innerhalb des Inhaltsbereichs möchtest du die Navigation und den Inhalt darstellen (=Ebene 2). Im Inhaltsbereich soll unter einem bestimmten Navigationspunkt eine Benutzerverwaltung eingebunden werden (=Ebene 3-4). Fasst du diesen Anwendungsfall mit MVC statt HMVC ab, bist du in deinem MVC-Controller gezwungen all diese Abhängigkeiten hinsichtlich der Anzeige im Controller abzubilden (siehe kürzliche Diskussion unter http://www.php.de/php-fortgeschrittene/ ... post639293) oder mit Hilfe von ViewHelpern auszugliedern. In beiden Varianten hast du jedoch nicht die Freiheit, Komponenten sauber zu kapseln und ohne gegenseitige Abhängigkeiten zu fomulieren.

Als weitere Lektüre kann ich dir empfehlen.
Bis auf der besseren Strukturierung, Gliederung durch die Spezialisierung und Einteilung verschiedener Ebene hat das HMVC keine weiteren Vorteile?
Indirekt schon:
  • Deutlisch bessere Wiederverwendbarkeit durch eindeutige Schnittstellen-Definition. Ein(e) Modul/Komponente ist nicht nur auf Ebene 5 sondern auch auf Ebene 1 lauffähig und kann daher separat getestet und durch den Schnittstellen-Vertrag in eine beliebige Seite/Applikation auf immer die selbe Weise eingebunden werden.
  • Du musst dir zwangsläufig Gedanken zum Url-Layout machen, da plötzlich nicht nur ein, sondern beliebig viele Controller und Komponenten angesteuert werden müssen. Dies führt - schon alleine auf Grund der Komplexität - zu generischen und sauberen Lösungen hinsichtlich der Url-Abstraktion und Filterung.
  • Um die Initialisierung einer HMVC-basierten Anwendung sinnvoll sicherstellen zu können sind Machanismen wie Front-Controller-Actions für die Business-Logik und Input- sowie Output-Filter für das Auflösen der Url-Layouts unabdingbar. Diese lassen sich jedoch nicht nur für die genannten Themen sondern auch für die Gestaltung der Applikation nutzen. Aus diesen Mögichkeiten ergeben sich dann beispielsweise Komponenten wie die htmlheader-Extension oder eigene Implementierungen für die Initialsierung der Anwendung, die globale Prüfung von Input etc.
HMVC per se scheint für dich zunächst wenig Auswirkungen auf die Vorgehensweise zuhaben, effektiv ist diese jedoch riesig und erfordert einiges an Umdenken beim Design einer Komponente.

Ich hoffe, das bringt dir das Thema etwas näher.
Viele Grüße,
Christian

dirtdevel
Beiträge: 28
Registriert: 26.12.2011, 23:51:51

Re: Struktur mit Framework, Fragen

Beitrag von dirtdevel » 28.12.2011, 23:05:10

Werde mir das in den kommenden Tagen mal alles durchlesen, wird bisschen dauern bis ich es verstanden habe.

Gruß,
dirtdevel

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste