nicht angemeldet
Hi!
Ok, das leuchtet mir ein. Ich schau mal, dass ich die DB-Klasse in meine Model-Klasse bringe und ob die Core-Klasse überhaupt nötig ist.
Ein Model muss nicht zwangsläufig ein DBMS befragen. Es kann die Daten auch aus einer anderen Quelle holen, sie dort ablegen oder sie einfach so berechnen. Ein Model kann sich einer DB-Klasse bedienen, aber es sollte nicht davon abgeleitet sein.
Gibt es denn auch Gründe _für_ eine Core-Klasse oder ist das allgemein eine schlechte Idee?
Im .NET-Framework gibt es eine Klasse Object, von der ist alle[*] anderen Klassen abgeleitet sind. Die stellt aber keine fachlichen sondern nur mehr oder weniger für das Framework interessante Dienste bereit. Es besteht jedoch keine unbedingte Notwendigkeit, eigene Klassen, die keine Erweiterung des Frameworks darstellen auch davon abzuleiten oder für diese ebenfalls eine Basisklasse zu erstellen.
Gründe lassen sich schon finden, aber sie sollten gut überlegt sein. _Keine_ Gründe wären zum Beispiel:
- bequeme quasiglobale Datenablage
- Bereitstellung globaler Dienste
Klassen sollen sich keine Dienste holen, weil dies Abhängigkeiten schafft, was man besser vermeidet. Besser ist es, ihnen die benötigten Werkzeuge mitzugeben, was auf den Namen Dependency Injection hört. Funktional gesehen sind sie zwar immer noch auf einen externen Dienstleister angewiesen, aber den kann man frei übergeben - mal diesen, mal jenen, mal nur einen Fake, wenn man Test machen möchte (zum Beispiel bei Test Driven Design).
[*] Vielleicht gibt es Ausnahmen, die sind mir aber nicht bekannt/begegnet.
Lo!