dedlfix: Framework Funkions Unterteilung

Beitrag lesen

Tach!

Welche Klassen (z.B. App, Router, Database, Sessions etc. ) in einem Framework fallen unter diese Kategorien:

Warum ist diese Frage für dich wichtig?

Venderors,

Was ist damit gemeint? Vendors = Verkäufer? Hab ich als Einteilung für Software noch nicht gehört. Finde ich auch nichts passendes beim Googeln.

Utils, Core, Helpers

Wo will man da die Grenzen ziehen? Besonders Utils und Helpers sind genauso wie Tools oder Infrastructure Synonyme für die Müllhalde, in die der Programmierer sein Kleinkramzeug einsortiert, für das er keinen besseren Verzeichnisnamen gefunden hat.

Core ist in dem Zusammenhang auch nicht besser.

Oder anders gesagt: Was gehört zu was?

Wenn es darum geht, die Verzeichnisse zu benennen, in die du deine Klassen einsortierst, dann kenne ich zwei grundlegende Verfahren. Einmal sortiert man die Dinge nach der technisch-strukturellen Zugehörigkeit. Zum Beispiel sortiert man als Verwender eines MVC-Frameworks alle dem Model zugehörigen Klassen ins Verzeichnis Models, alle Controller zu Controllers, die Views unter Views. Das ist mitunter vom Framework so vorgegeben, weil es die Klassen in den entsprechenden Verzeichnissen sucht. Das nennt man dann Convention over Configuration. Statt konkret zu konfigurieren, wo das Framework nach bestimmten Dingen suchen soll, schaut es in Verzeichnissen mit vorgegeben Namen nach.

Man spart sich damit einen Konfigurationsschritt. Und das macht es auch aus Sicht des Frameworks einfacher, weil es diese Konfiguration nicht auswerten muss, hat aber auch zum Nachteil, dass man die fachlich zusammengehörenden Dinge voneinander trennt. Zum Beispiel bilden der XY-Controller mit seinen XY-Views und den XY-Models eine fachliche Einheit. Fachlich in dem Sinne, dass damit eine Einheit aus dem Anforderungskatalog des Auftraggebers gemeint ist. Ein Teil der Software soll sich beispielsweise mit Kunden beschäftigen, ein anderer mit Produkten und ein dritter mit der Buchhaltung. Und wenn man gerade an einem dieser Themen arbeitet, muss man zwischen drei verschiedenen Verzeichnissen hin- und herwechseln, um dessen Models, Controllers und Views zu bearbeiten.

Andererseits ist auch diese zweite Sortierweise nicht immer die beste. Es kann auch Dinge geben, die man fachübergreifend verwenden möchte. Kunden und Produkte braucht man gemeinsam für die Themen Shop, Verkauf und Lieferabwicklung.

Wenn man ein generelles Framework für Anwendungen schreibt, weiß man ja noch nicht, was am Ende die fachlichen Anforderungen aus Sicht des Verwenders sind. Man kann deshalb vorwiegend nur schauen, was für das Framework an sich gut ist und nur ganz grob Hilfen für eine anderweitige Strukturierung anbieten. Zum Beispiel bietet ASP.NET MVC Areas an, in denen man Controllers und Views bündeln und von anderen Areas trennen kann. Die Dinge für die Administrationsoberfläche könnten in eine Area einsortiert werden, das was der normale Anwender sieht, in eine weitere.

Wie sortiert man nun ein Framework? Das ist vor allem auch eine Frage der persönlichen Sichtweise. Was für den einen zum Kern gehört, ist für den anderen nur Beiwerk. Solche allgmeinen Namen wie Core oder Tools/Utils/Helpers sind im Grunde genommen nichtssagend. Man kann aus Außenstehender daran nur schwer bis gar nicht erkennen, wo wohl das sein wird, was man gerade sucht. Wenn man eine das Routing betreffene Klasse sucht und die in einem Verzeichnis namens Router findet, dann kann man sich schneller und einfacher durch den Code bewegen, weil die sprechenden Bezeichnern eine gute Orientierungshilfe darstellen.

dedlfix.