nicht angemeldet
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.
MudGuard