Erläuterung der Zuständigkeit der Klassen in jedem Ordner im Framework

[MB]

moin,

Mir ist bewusst welche Klassen und HTML-Dateien in den Ordnern Models, Views und Controllers im Framework sind und wofür sie zuständig sind. Aber ich finde die Zuständigkeit und Funktion der Klassen unter den folgenen Ordnern nicht heraus 😕

• services
• utils
• helpers
• handlers
• storage
• resources
• events
• listeners
• modules
• tools

Müssen die Klassen in diesen Ordner irgend eine Funktion (haben/nicht haben) um in diesen Ordnern zu sein???

lgmb

PS: Ich hab diese Frage in anderer "schlechterer" Formulierung schgonmal gestellt.

[MudGuard]

Hi,

Mir ist bewusst welche Klassen und HTML-Dateien in den Ordnern Models, Views und Controllers im Framework sind

in welchem Framework?

Was sagt die Doku dieses Frameworks dazu?

cu,
Andreas a/k/a MudGuard

[MB]

moin MudGuard,

Mir ist bewusst welche Klassen und HTML-Dateien in den Ordnern Models, Views und Controllers im Framework sind

in welchem Framework?

Was sagt die Doku dieses Frameworks dazu?

Die Doku werde ich schreiben. Is ja mein Framework was in der entwicklung is

lgmb

[MudGuard]

Hi,

Mir ist bewusst welche Klassen und HTML-Dateien in den Ordnern Models, Views und Controllers im Framework sind

in welchem Framework?

Is ja mein Framework was in der entwicklung is

Und dann weißt Du nicht, welche Dateien Du (warum) in welche Ordner gesteckt hast?

cu,
Andreas a/k/a MudGuard

[MB]

moin,

Mir ist bewusst welche Klassen und HTML-Dateien in den Ordnern Models, Views und Controllers im Framework sind

in welchem Framework?

Is ja mein Framework was in der entwicklung is

Und dann weißt Du nicht, welche Dateien Du (warum) in welche Ordner gesteckt hast?

Nein, alles ok soweit. Ich plane nur Funktionalitäten zu erweitern. Ich hab teilweise schon die funktionalität nur ich will das separat schön verpackt wissen. Denn die Funktionalität hat einen anderen Zuständigkeitsbereich als meine bisherigen kategorien 😉.

lgmb

[pl]

hi @MB

Mir ist bewusst welche Klassen und HTML-Dateien in den Ordnern Models, Views und Controllers im Framework sind

in welchem Framework?

Was sagt die Doku dieses Frameworks dazu?

Die Doku werde ich schreiben. Is ja mein Framework was in der entwicklung is

Das ist eine seltsame Herangehensweise. Die vermutlich nur dazu führt, ein bereits vorhandenes Framework zu kopieren. Wenn Du was lernen willst, dan lerne eigene Ideen umzusetzen.

MfG

PS: Was ich von anderen Frameworks gelernt habe ist eher wie man es nicht macht!

[MB]

moin,

hi @MB

Mir ist bewusst welche Klassen und HTML-Dateien in den Ordnern Models, Views und Controllers im Framework sind

in welchem Framework?

Was sagt die Doku dieses Frameworks dazu?

Die Doku werde ich schreiben. Is ja mein Framework was in der entwicklung is

Das ist eine seltsame Herangehensweise. Die vermutlich nur dazu führt, ein bereits vorhandenes Framework zu kopieren. Wenn Du was lernen willst, dan lerne eigene Ideen umzusetzen.

keines wegs. ich sammle von vielen "einfachen" Frameworks um selbst ein Framework zu entwickeln im Sinne von "Lerning by Doing". Einfach weil es von komplexen wie Laravel, Symfony, Zend Framework oder Cake PHP sehr viel Zeit in anspruch nehmen würde um da durch zu steigen. Außerdem ist es nicht ein sondern viele Entwickler die ein Framework konstruieren.

Meine Frage zielt eben auf erweiterte Funktionalitäten ab. Funktionalitäten deren Zuständigkeitsbereich sich nicht in meiner Framework-Struktrur abbilden lassen. Also will ich einen Themenbereich erweitern um die Funktionalitäten in der Framework-Struktur zu integrieren.

lgmb

[pl]

hi @MB

wenn ich Dir da mal einen Tipp geben darf: Ein Framework ist im Grunde genommen auch nur eine Libary von Klassen und Interfaces. Und da ich von Perl komme: Da ar es schon immer so üblich, Klassenhierarchien auf Verzeichnisstrukturen abzubilden. Und das hat auch seine vielen guten Gründe.

Schönen Sonntag.

PS: In PHP heißen Klassen die was erben Klassenerweiterungen. Lass Dich von diesem Begriff nicht verwirren. Denn in der Mehrheit praktischer Anwendungen erweitert eine abgeleitete Klasse nämlich gar nicht sondern spezialisiert.

[MB]

moin,

Ein Framework ist im Grunde genommen auch nur eine Libary von Klassen und Interfaces. Und da ich von Perl komme: Da ar es schon immer so üblich, Klassenhierarchien auf Verzeichnisstrukturen abzubilden. Und das hat auch seine vielen guten Gründe.

ich weis.

ich wünsche dir ebenfals einen schönen sonntag abend

lgmb

[dedlfix]

Tach!

Mir ist bewusst welche Klassen und HTML-Dateien in den Ordnern Models, Views und Controllers im Framework sind und wofür sie zuständig sind.

Ein MVC-Framework besteht üblicherweise nicht nur aus dem Muster MVC. Das ist nur das Hauptmerkmal, aber es stecken noch jede Menge andere Komponenten drin, die ihrerseits auch wieder bestimmten Programmiermustern folgen können. Beispielsweise muss es auch noch Bindeglieder zu den anderen Beteiligten der Anwendung geben.

Die Geschäftslogik beispielsweise findet nur bei sehr kleinen Projekten ihren Platz direkt im Controller, bei größeren wird es unübersichtlich und man lagert sie besser in Services aus. Vor allem dann, wenn eine bestimmte Funktionalität an mehreren Stellen benötigt wird, hat man sie lieber an einer Stelle anstatt als Kopie im Code verteilt. Ein

• services

erledigt also eine bestimmte fachliche Aufgabe.

• utils
• helpers
• tools

sind ziemlich nichtssagende Namen und dienen üblicherweise als Sammelbecken für Kleinkram, den man sonst nirgends zuordnen kann. Beliebt ist da auch der Name infrastructure für diese Art "Müllhalde".

• storage

Darin werden wohl Dinge liegen, die sich um die Persistierung von Daten kümmern.

• resources

Ressourcen sind üblicherweise eine Quelle für statische Daten, beispielsweise Icons und andere Bilder oder auch Multimedia-Elemente der Benutzeroberfäche. Auch Dateien mit den Texten für die Lokalisierung können dort liegen.

• handlers
• events
• listeners

Handler und Listener sind mehr oder weniger Synonyme für diejenigen Teile, die auf Events reagieren und das was dann zu tun ist ausführen oder ausführen lassen.

Events hängen üblicherweise an einem Bedienelement oder einer rückwärtigen Komponente, sind also allein nicht lebensfähig. Aber wenn so ein Event ausgelöst wird, sind auch ein paar Daten dazu an den Handler zu übergeben, je nach Art des Event unterschiedliche. Die Definitionen dieser Datenklassen kann man dort einsortieren. In manchen Umgebungen sind Events auch eigene Datentypen (zum Beispiel in C#), die dann auch separat definiert werden.

• modules

Das ist ein ganz besonders nichtssagender Name. Ein Modul ist üblicherweise eine Sammlung von Komponenten, die einem fachlichen Thema zugeordnet werden können. Somit ist das ein Sammelbecken, das Komponenten der oben genannten Arten vereinen kann.

Überhaupt ist das ein Thema, wie man sei Projekt strukturiert, so dass man die Dinge schnell findet und nicht alles auf einem großen Haufen liegt. Die Dinge nach technischen Eigenheiten oder Programmiermustern zu sortieren ist zwar beliebt, aber ich finde das nicht sonderlich sinnvoll. Als Ersteller eines Framework, der keine Ahnung hat, für welchen fachlichen Verwendungszweck es bei den Nutzern letztlich eingesetzt wird, kann es auch nicht nach fachlichen Gesichtspunkten ordnen. Und so entsteht dann eine Ordnung wie die oben gezeigte, die aus dessen Sicht sinnvoll erscheint. Als Verwender kann man dieser Philosophie folgen, oder sie aber ignorieren und seiner eigenen Ordnung nachgehen. In einem Unternehmen bildet man die Abteilungen auch nicht so, dass man alle Teamassistenten und andere Tätigkeitsgruppen zusammenfasst, sondern sie nach Thema sortiert. Auch die individuellen Arbeitsmittel sind in der Nähe der fachlichen Mitarbeiter. Keiner kommt heutzutage mehr auf die Idee, Computer nur in einem einzigen Raum aufzustellen statt sie an den Arbeitsplätzen der fachlichen Abteilungen vorzuhalten. Ausnahmen bestätigen die Regel, vor allem wenn es rückwärtige Dienste sind, die für alle da sind. Die IT-Abteilung wird auch weiterhin Server gemeinsam in ein Rechenzentrum stellen, weil das aus anderen Gesichtspunkten sinnvoll ist. Die Kantine wir auch zentralisiert sein, Getränke- und Snack-Automaten sowie andere Kleingeräte zur Nahrungszubereitung stehen aber auch gern in Fachabteilungsnähe.

Müssen die Klassen in diesen Ordner irgend eine Funktion (haben/nicht haben) um in diesen Ordnern zu sein???

Natürlich gibt es da keinen generellen Zwang. Es kann sinnvoll sein, die Dinge fachlich oder technisch oder gemischt zu sortieren. Gelegentlich gibt es aber Vorgaben, die aufgrund von Konventionen vorhanden sind. Bei ASP.NET MVC ist der Ordner Views vorgegeben. Damit liegen die Views aber abseits der Controller, denen sie üblicherweise zugeordnet sind (abgesehen von Shared-Dingen wie dem Grundlayout). Das hat aber auch den Vorteil, dass man nicht den kompletten Pfadnamen angeben muss, sondern das Framework kann diesen aufgrund der Konvention selbst bilden. Letztlich ist das alles eine Abwägungssache und den goldenen Mittelweg, der für alle das beste ist, gibt es schlichtweg nicht. So wirst du Frameworks finden, die sich nach der einen oder der anderen Philosophie organisieren.

dedlfix.

[MB]

moin,

Vielen Herzlichen Dank und sehr strukturiert und schöne veranschaulichungen. Das bringt mich extrem weiter. Danke Dir.

lgmb

PS: übrigens mein multilinguales Framework wächst und ich schreibe an einer Contact- & Login-Funktion und einer kleinen Template-Engine. Aber LAF bin ich noch nicht