[Erledigt] MVC-Framework: Modulsystem

[bitsnack]

Hi,

Ich bin neu hier und hoffe hier das richtige Forum für mein Probem gefunden zu haben. Ausserdem würde es mich freuen wenn mein Thema wie bei allen anderen grösseren Foren nicht einfach in der Masse untergehen würde, und wir eine gute Lösung dafür finden.

Ich schreibe zurzeit ein PHP5-MVC-Framework für den privaten Gebrauch, weil ich mir erhoffe dadurch einige Dinge zu lernen und Frameworks danach besser verstehen und benutzen zu können.
Zurzeit stehe ich aber noch vor einem Aufbau-technischen Problem, zudem mir keine akzeptable Lösung einfällt.

Ich versuche in meinem Framework ein Modulsystem zu integrieren.
Ein Modul besteht aus einem Modul-Controller und den benötigten Dateien wie z.B Views und Models oder auch andere Klassen, welche man sonst schwer einordnen kann. Diese Module sollen Libraries ersetzen, oder deren Möglichkeiten zumindest erweitern. Ein Modul soll genau wie eine Library genutzt werden können, und soll deshalb auch den gleichen Gesetzen der Ordner-Struktur unterliegen, um den Entwickler nicht zu verwirren oder zur Unterscheidung zwischen Modulen und Libraries zwingen zu müssen.

Zwei Beispiele: Die Datenbank-Library benötigt Datenbank-Treiber, und die Scaffolding-Library eigene Views und Models. Diese Dateien möchte ich bündeln, um die Übersicht und Verwaltung zu vereinfachen und zu klären.

Ein Modul soll jeweils eine eigene Config-Datei besitzen, welche zur besseren Übersicht in einem abgesonderten Config-Ordner platz finden soll.
Auch Interfaces die von den Klassen eines Moduls benötigt wird, sollte irgendwie zum Modul gehören.

Nun habe ich zu dem ganzen mal 2 Vorschläge:

1) Ein Modul ist eine Erweiterung zu einer Library. Die Library kontrolliert die Dateien des Moduls und nutzt sie. Die Config ist in einem abgesonderten Ordner, genauso wie die Interfaces, damit diese auch von anderen Klassen genutzt werden können. => Nachteil: Es wird jeweils ein eigenes System zur Erweiterung von Libraries und Interfaces und den Modul-Dateien benötigt und die Dateien welche ein Modul benötigt liegen teilweise verstreut.

2) Jedes Modul hat einen Modul-Controller, welcher im Vergleich mit der ersten Möglichkeit die Aufgabe der Library übernimmt. Jede Library ist ein Modul und bündelt somit die für die Library benötigten Dateien, mitsamt den Interfaces. => Nachteil: Interfaces können nicht von Klassen anderer Module genutzt werden, und die Erstellung einer einfachen Library wird durch zusätzliches Anlegen eines Modul-Ordners erschwert. Dafür sind alle Dateien die ein Modul benötigt gebündelt.

Habt ihr bessere Ideen, Verbesserungsvorschläge, Tipps oder ähnliches?

Vielen Dank im Voraus!

greez

bitsnack

[singu]

Veröffentlichst du dein MVC-Framework irgendwann?

[nikosch]

Ein Modul besteht aus einem Modul-Controller und den benötigten Dateien wie z.B Views und Models oder auch andere Klassen, welche man sonst schwer einordnen kann. Diese Module sollen Libraries ersetzen, oder deren Möglichkeiten zumindest erweitern. Ein Modul soll genau wie eine Library genutzt werden können, und soll deshalb auch den gleichen Gesetzen der Ordner-Struktur unterliegen, um den Entwickler nicht zu verwirren oder zur Unterscheidung zwischen Modulen und Libraries zwingen zu müssen.

Sorry, aber das ist mir zu abstrakt. Wenn Du von Modulen sprichst - auf welcher Ebene fungieren diese? Wo ist der Unterschied zur Library?

[bitsnack]

Veröffentlichst du dein MVC-Framework irgendwann?

Ja, höchstwahrscheinlich schon. Aber ich schreibe das Framework nicht für diesen Einsatz, sondern eben für meinen eigenen Gebrauch (und den von Kollegen), und veröffentliche es nur so nebenbei…

Sorry, aber das ist mir zu abstrakt. Wenn Du von Modulen sprichst - auf welcher Ebene fungieren diese? Wo ist der Unterschied zur Library?

Zurück zu meinen Beispielen: Einige "Libraries" benötigen eben weitere Klassen, oder auch Views und somit einige Icons etc…
Die Datenbank-Library ist für Anfragen an eine Datenbank gedacht - und zwar an eine möglichst breite Palette von unterschiedlichen Datenbanksystemen. Dazu benötigt es Datenbanktreiber, bzw. Klassen, welche die Eigenheiten von diesem Datenbanksystem festlegt und eine einheitliche Schnittstelle dazu deklariert. Diese Datenbanktreiber müssen irgendwo gespeichert sein, sie sollen der Datenbank-Library zugeordnet sein und auch ganz einfach erweitert werden können. Jetzt will ich nicht zu jeden von einer Library benötigten Dateien irgendeinen zusätzlichen Ordner machen, sondern indem ich diese Dinge in einem Modul bündle einheitlich verwalten und nutzen kann.

Die Module sind also eigentlich nichts anderes als ein Packet einer Library und den dafür benötigten Dateien.

[nikosch]

Dann stimmt das aber nicht:

Die Library kontrolliert die Dateien des Moduls und nutzt sie

Die Library kann ja das Modul nicht kennen, wenn das Modul die äußere Struktur darstellt.

Und das ist dann auch unstimmig:

Jedes Modul hat einen Modul-Controller, welcher im Vergleich mit der ersten Möglichkeit die Aufgabe der Library übernimmt.

Haut auch nicht hin, wenn eine Library für sich alleinstehend eine Schnittstelle definiert. Genau genommen kann es keine Lösung dafür geben - entweder die Bibliothek bestimmt die Schnittstelle, dann kann man aber nicht davon ausgehen, dass ein Modul mehrere Bibliotheken in einer gemeinsamen Schnittstelle bündeln kann*) oder das Modul bestimmt das Interface, dann ist genau genommen gar keine Trennung in Module und Bibliotheken notwendig.

*) jedenfalls keine einheitliche. Du kannst natürlich im Modul nach Art des Fascade-Patterns eine eigene Schnittstelle definieren. Das hätte den Vorteil, dass Du auch nicht-gemeinsame Funktionalitäten verschiedener Bibliotheken ansatzweise wrappen kannst und ggf. als Workaround umsetzen. Sowas wie LIMIT n,m bei SQL/MySQL

[bitsnack]

Hm, ich glaube du hast da was falsch verstanden, wahrscheinlich weil ich es schlecht erklärt habe:

Mal ein Vergleich:
Die Library ist ein HTML-Dokument. Sie benötigt noch ein Stylesheet, einige Bilder und noch 2 Javascript-Dateien. Ein Modul ist in dem Vergleich als nicht anderes als ein Ordner, in welchem sich diese Website befindet. Das einheitlich ansprechbare ist nur die Library des dazugehörigen Moduls (Library und "Modul" bzw. die restlichen benötigten Dateien gehören immer zusammen).

Ist wirklich schwer zu erklären, wenn man ja gerade ein System dafür sucht:
Eine Library benötigt zusätzliche Dateien welche keine eigenständige Library sein können (müssen ja nichtmal Klassen sein). Diese Dateien möchte ich mit der Library die sie benötigt bündel. Wie man das nennen will ist ja wurst: Modul, Bundle oder was auch immer. Jedenfalls suche ich nicht nach einem Code wie man das genau umsetzen und ansprechen kann, sondern nach einer Idee wie man sowas von der Ordner-/Datei-struktur am besten lösen könnte. Ich nenne Module absofort lieber Bundle, weil das vielleicht zu weniger Missverständnissen führt.

Ich habe eine Library und X andere benötigte Dateien dieser. Soll die Library in den Ordner des Bundles, oder gehört das Bundle einfach zur Library. Das Bundle selbst kann ohne die Library garnix. Die Library nutzt nur die Dateien in diesem Bundle.
Wenn jetzt die Libraries mit in den Ordner des Bundles tue, muss ich das auch bei Libraries machen, welche keine anderen Dateien benötigen. Dann müsste man einfach einen Ordner (= Bundle) anlegen, wo man nur die Library reintut. Somit würde das erstellen einer stinknormalen einfachen Library schwieriger werden. Mache ich es aber extern, ist die Library nicht mehr so eindeutig mit dem Bundle verbunden…

Ist reine Planungssache: Library ins Bundle oder nicht, Interfaces ins Bundle oder nicht, oder andere Ideen wie man mit dem Problem zusätzlich-benötigter Dateien besser umgehen kann?

PS: Eine Art HMVC für Libraries

[nikosch]

Die Library ist ein HTML-Dokument. Sie benötigt noch ein Stylesheet, einige Bilder und noch 2 Javascript-Dateien. Ein Modul ist in dem Vergleich als nicht anderes als ein Ordner, in welchem sich diese Website befindet. Das einheitlich ansprechbare ist nur die Library des dazugehörigen Moduls (Library und "Modul" bzw. die restlichen benötigten Dateien gehören immer zusammen).

Also dieses Beispiel ist _wirklich schlecht_, wenn man über Frameworkentwicklung spricht.

Eine Library benötigt zusätzliche Dateien welche keine eigenständige Library sein können (müssen ja nichtmal Klassen sein). Diese Dateien möchte ich mit der Library die sie benötigt bündel. Wie man das nennen will ist ja wurst: Modul, Bundle oder was auch immer.

Das macht doch alles keinen Sinn. Sobald eine Komponente von mehreren Bibliotheken benötigt wird, solltest Du sie optimieren und dann als Core-Komponente des Frameworks umsetzen, von denen jede Library die garantierte Existenz annehmen kann. Konkret implementiert werden könnte das dann bspw. durch Including aller Core-Komponenten bzw. mit Autoloadern für desssen OO-Elemente.

[Gast]

Das klingt sehr nach dem Fehler, den viele machen, die ihr Framework/CMS möglichst flexibel halten wollen -> Am besten die komplette Struktur in irgendwelche Module/Plugins auslagern, die sich per Interface oder sonst wie ins Framework einbetten lassen.

_Das_ funktioniert so nicht. Man kann _nicht_ alles generisch abbilden. Module/Plugins sollten sich auf einer Ebene der Applikation bewegen, nicht in den verschiedenen Schichten. Damit meine ich, Module können nicht wie oben, einmal Datenbank und einmal Scaffolding-Form sein. Das funktioniert nicht!

Irgendwann steht man vor dem Problem, dass das eine "Modul" etwas spezialisiertes anbieten muss und dann noch was usw. Aus gutem Grund wurde das bisher von keinem anderen Framework so umgesetzt. Und dann hat man schon wieder etwas, für das man nur eine Klasse/Ein paar Funktionen benötigt, ohne das Modul-Drumherum..

Vor Jahren hatte ich diesen Ansatz mal ausprobiert: Sämtliche Bestandteile wurden in "Module" verpackt, die sich über eine generische Schnittstelle einbinden ließen. Damit war der Ansatz allerdings schon am Ende, denn die Benutzung z. B. einer DB-Verbindung lässt sich nun mal nicht auf einen Nenner mit einer Formular bringen.

Daher -> Module funktionieren meist nur auf einer Ebene (z. B. Kontaktformular oder Gästebuch - Mal ganz allgemein)..

[bitsnack]

Vielen Dank für die hilfreichen Beiträge, das Thema ist damit wohl erledigt. Mein Framework werde ich noch verschieben und mich doch noch lieber mit anderen Patterns, Frameworks und vorallem Sprachen beschäftigen, weil PHP bestimmt nicht meine erste Wahl wäre...

[nikosch]

Hmm, sonderbare Idee, sich dann an ein Framework zu machen.