Framework Funkions Unterteilung

[MB]

Moin Community,

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

Venderors, Utils, Core, Helpers

Oder anders gesagt: Was gehört zu was?

vlg MB

[pl]

Session und Database würde ich unter Data Access Layer einordnen. Wenn Sessiondaten anfallen, z.B. ein Login, müssen die ja persistent gemacht werden. Ich beschränke mich hier mal auf die Session, weil ich da in den letzten Tagen was gemacht habe, das ist noch fisch:

package main;

# Das ist die Router Class

# noch vor der Erstellung der
# Framework Instanz
# $sid ist die Session Id und der Dateiname
if($sid){
   tie %SESSION, 'SessionHash', file => $sid or die $@;
}

# sobald der Router die App Class festgestellt hat
# wird %SESSION
# zur Eigenschaft der Framework Instanz gemacht

# und immer dann, wenn es in der Session was zu speichern gibt
# $self ist die Framework Instanz
# in App Class Login
# Logindaten (username, Zeitstempel, Group) speichern
tied(%{$self->{SESSION}})->write;

Schönen Sonntag.

Stichworte Aggregation, Delegation

[dedlfix]

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.

[Nils-Hero]

Stimme dedlfix zu. Meiner Meinung nach sollte die Einteilung zuerst die Funktionalität für den Nutzer sein, dann erst die Funktionalität für das Framework.

Also beispielsweise für eine Schachanwendung:

Core [1]
    database
    res
    bin
    conf
Engine
    res
    bin
    conf
Tablebases
    ...
PGN
    ...
Polyglot
    ...

Ich verwende <Name> für Ordner die die Nutzerfunktionalität beschreiben und <name> für technisch-strukturelle Ordner (siehe dedlfix´s Post). Das ist natürlich eine persönliche Präferenz (aber beispielsweise Python macht es ähnlich). Ein smartes Framework könnte aus dieser Namenskonvention dann z.B. ableiten, wo es suchen muß.

Nach 'Core' packe ich während der Entwicklung alles hin für das ich noch keinen passenden Namensraum gefunden habe. Man kann auch 'Misc' nehmen oder den Ordner ganz weglassen und dessen Kindordner direkt ins Rootverzeichnis packen.

Gruß, Nils

[MB]

Moin dedlfix,

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.

Ich auch nicht. Trotzdem tauchen sie bei Framework Tutorials immer auf 😕. sehr suspekt.

Also erstmal besten Dank für die AW. Das war genau das was ich wissen wollte.

vlg MB