nicht angemeldet
Tach!
Ich wollte halt die eigentlichen Entitätsklassen sehr schmal halten und Wiederkehrendes eben zentral behandeln.
Schlank (schmal wird es, wenn du im Editor den Umbruch auf 20 Zeichen stellst) sind deine Klassen aber nicht wirklich. Wenn du das schlank nur auf die "eigentlichen Entitätsklassen" beziehst, dann betreibst du sozusagen Eigenaugenwischerei, weil du den fetten Unterbau ausblendest. Wiederkehrendes kann man auch vermeiden, indem man die Zuständigkeiten trennt. Deine Entitätsklassen brauchen den Datenbankzugriff nur an bestimmten Stellen deines Programms. An anderen, beispielsweise bei der Ausgabe, braucht es diesen Unterbau nicht. Deswegen ist Active Record für das große Ganze nur bedingt nützlich und im Rest bestenfalls überflüssig.
Nehmen wir mal an, du möchtest in Zukunft deine Entitäten serialisieren, weil du sie als JSON an die SPA senden möchtest. Du musst dann berücksichtigen, was von der Klasse zum Active Record gehört und damit übergangen werden muss. Kein Problem, sagst du dir, bau ich das noch in die Basisklasse ein. Und dann kommt die nächste Anforderung, die auch wieder ... und irgendwann hast du eine eierlegende Wollmilchsau mit all ihren Nachteilen aufgrund ihrer Komplexität. Deswegen gibt es Programmiermodelle, die wirklich auf schlanke Bestandteile bedacht sind. Zum Beispiel immer, wenn in der Beschreibung, was ein Ding macht, das Wort "und" vorkommt, ist das ein guter Indikator um über die Trennung von Zuständigkeiten nachzudenken. Lösungen gehen zum Beispiel in die Richtung, dass Datenbankabfragen für jedes Entity in einem eigenen Repository abgehandelt werden, das seinerseits sich der Dienste der Datenbankabstraktion bedient. Meist reicht in typisierten Sprachen wie C#, dass man sich da ein generisches Repository mit der grundlegenden CRUD-Funktionalität baut, das man dann lediglich konkret typisiert instantiiert. Vorgänge der Geschäftslogik werden von Services erbracht. Das beinhaltet auch komplexe Datenverarbeitungsvorgänge über mehrere Entitäten hinweg, was man dann mit einem Unit of Work kapselt. Auch das Übersetzen wäre eine Tätigkeit für einen Service. Der kann auch gut und gerne seinerseits entsprechende Repositorys und andere Services befragen, um seine Aufgabe zu erledigen.
Leider hat diese Trennerei auch wieder einen Nachteil. Man möchte nämlich auch nicht, dass all diese Services ihrerseits wild um sich greifen, um das heranzuziehen, was sie zum Arbeiten brauchen. Es ist auch nicht besonders schön, wenn man all diese Abhängigkeiten zu Fuß auflösen muss, bevor man auch nur mit einem einzigen Service arbeiten kann. Und da ist dann der nächste Schritt hin zur Dependency Injection und einem DI-Framework, das diese Abhängigkeiten eigenständig auflösen kann.
Vielleicht wirst du diesen Weg nicht gehen wollen, weil das wohl einen kompletten Umbau deines Programms bedeuten würde, aber ich wollte es wenigstens mal erwähnt haben.
dedlfix.
Rolf B