nicht angemeldet
Hallo,
Aha, Missverständnis geklärt,
Dafuer hakt es jetzt bei mir ;-)
Du willst die gesamte Datenstruktur in der Programmlogik halten, gelegentlich wird
dann ein "Kunde.Save()" rausgehauen. Das nötige SQL »» wird hübsch gekapselt und die
Kenntnis desselben spielt für den Entwickler der Geschäftslogik keine Rolle.
Richtig.
So weit, so breit. Dummerweise gibt es diese Unabhängigkeit in der Praxis nicht, es
muss immer brav nachSQLt werden, wenn an den Geschäftslogikobjekten etwas geändert wird.
Ich vergaß, reden wir jetzt ueber einen spezielle Fall oder ueber Schichten an sich?
Im letzteren Falle existieren ja extra 3 Schichten, damit die Geschaeaftslogik unabhaengig
von den darunter liegenden Schichten ist.
Zur Veranschaulichung hier einmal die Schichten, von denen ich die ganze Zeit rede:
1. PO's (Persistenzobjekte)
Besitzen das Mapping der Datenbank zu Objekten - so wie Persistierungsfunktionen (Retrieve,
Select, Update, Insert)
2. PA's (Persistenz-Adapter)
Hier findet die Abstrahierung des jeweiligen PO's statt. Variablen/Objekte koennen geaendert,
Validitaetspruefungen implementiert und die Objekte erweitert werden.
3. BO's (Business-Objekts)
Hier findet die eigentliche Geschaeftslogik statt.
Zudem, und das ist jetzt mein Hauptargument gegen RDBMS+OOP, muss eine neue Schicht
eingezogen werden. Dieses ist aufwendig in Erstellung und Pflege, zudem oft einfach
doppelt gemoppelt (wenn die Persistierung der Objekte bspw. nur auf einem System
(einem RDBMS) erfolgt und nicht auf mehreren).
Naja, das ist Geschmackssache ;-)
Gruesse aus Berlin
Christopher