nicht angemeldet
Hallo Sven,
Würde ich gar nicht tun.
Meine Klassen orientieren sich immer an der zu erledigenden Aufgabe -
nicht an der Datenbank.
Das sind zwei grundsaetzlich verschiedene Ansaetze: zum einen der datenbankbasierte, und zum anderen der anwendungsbasierte. Beide Ansaetze koennen jedoch auch aufeinander aufbauen, so dass man einen Mehrwert erhaelt. Nicht selten dient ersterer als grundsaetzliche Basis. Auf diesem Layer aufbauend kann man dann die Businesslogik und -Objekte erstellen.
Ich zum Beispiel mag es lieber, wenn ich eine Objektabbildung der Datenbanktabellen als Grundlage habe. Bei diversen Persistenceframeworks wird es ja groesstenteils auch so implementiert. Das heisst, man arbeitet in diesem Fall mit mehreren Layern: Dem Persistencelayer, dem Persistence-Adapter und dem Businesslayer. (Hinzu kommt dann schliesslich noch die Repraesentationsschicht). Erstere ist eine identische Abbildung der Datenbankbeziehungen. Das heisst im Falle der Tabelle Person und Adresse, besaesse das Objekt Person ein Referenzobjekt auf die Adresse. Im Code der Klasse Person existiere also eine GetAdresse-Methode, die das zugehoerige Adress-Objekt liefert. Dieses wiederum besaesse zum Beispiel ein Dependency-Objekt, was uns das ihm zugewiesene Country-Objekt liefern wuerde.
Wie bereits erwaehnt, mag ich diesen Ansatz, da man zum einen recht leicht anhand des Datenbankschemas arbeiten kann und, zum anderen, die einzelnen Schichten gut voneinander getrennt und gekapselt werden.
MfG,
Sympatisant
"Non dura iubeantur, non prohibeantur inpura."