JavaScript ist deaktiviert. Für eine bessere Darstellung aktiviere bitte JavaScript in deinem Browser, bevor du fortfährst.

Auf Thema antworten

Nachricht

Ich hatte mal Projekt mit DB4OJ gearbeitet und hier sind ein Paar Erfahrungen
gegenüber rel. DB spart man in wrapper schicht viel Arbeit (statt SQL-Befehl zu schreiben), aber :bae: mit Vorsicht zu geniessen. DB4O speichert die Object-Struktur mit (SuperClass, Interface, Parameter...) und wie, was genau...? Wir können nicht nachvollziehen. Sollten wir später die Objekte mal seine Strukturen ändern (was sich aber oft während einer Projekt passiert!), es sei neue Interface, mal neue Parameter (z. B. Object Adresse wird Param PLZ hinzugefügt...), dann ist die vorhandene Datenbank unlesbar.
Die Wrapper-Objects, die durch store() in die DB speichert, sollen also sich nicht beliebig seine Struktur ändern. Daher sollen sie möglich von Business-Schicht (Anwendungsschicht) fern und umgekehrt sollen business-Objects niemals direkt durch store(), delete()...mit DB kommunizieren lassen. Jede store(WrapperObject), retrieve(WO), delete(WO) in Wrapper-Schicht... sollen entsprechende Methoden store(BussinesObject), select(BO), delete(BO)... in Persistence-Schicht zuordnen und umgekehrt. Somit können wir bussiness-Objects und seine Struktur während einer Projekts oder später ändern und anpassen.
Also braucht mal schon gewisse Gedanke am Anfang einer Projekt, wie die Wrapper-Objects aufgebaut sind.

<blockquote data-quote="andy82" data-source="post: 982972" data-attributes="member: 30615"><p>Ich hatte mal Projekt mit DB4OJ gearbeitet und hier sind ein Paar Erfahrungen</p><ul>
<li data-xf-list-type="ul">gegenüber rel. DB spart man in wrapper schicht viel Arbeit (statt SQL-Befehl zu schreiben), aber :bae: mit Vorsicht zu geniessen. DB4O speichert die Object-Struktur mit (SuperClass, Interface, Parameter...) und wie, was genau...? Wir können nicht nachvollziehen. Sollten wir später die Objekte mal seine Strukturen ändern (was sich aber oft während einer Projekt passiert!), es sei neue Interface, mal neue Parameter (z. B. Object Adresse wird Param PLZ hinzugefügt...), dann ist die vorhandene Datenbank unlesbar.</li>
</ul>
<ul>
<li data-xf-list-type="ul">Die Wrapper-Objects, die durch store() in die DB speichert, sollen also sich nicht beliebig seine Struktur ändern. Daher sollen sie möglich von Business-Schicht (Anwendungsschicht) fern und umgekehrt sollen business-Objects niemals direkt durch store(), delete()...mit DB kommunizieren lassen. Jede store(WrapperObject), retrieve(WO), delete(WO) in Wrapper-Schicht... sollen entsprechende Methoden store(BussinesObject), select(BO), delete(BO)... in Persistence-Schicht zuordnen und umgekehrt. Somit können wir bussiness-Objects und seine Struktur während einer Projekts oder später ändern und anpassen.</li>
</ul>
<ul>
<li data-xf-list-type="ul">Also braucht mal schon gewisse Gedanke am Anfang einer Projekt, wie die Wrapper-Objects aufgebaut sind.</li>
</ul></blockquote><p></p>

[QUOTE="andy82, post: 982972, member: 30615"] Ich hatte mal Projekt mit DB4OJ gearbeitet und hier sind ein Paar Erfahrungen [LIST]gegenüber rel. DB spart man in wrapper schicht viel Arbeit (statt SQL-Befehl zu schreiben), aber :bae: mit Vorsicht zu geniessen. DB4O speichert die Object-Struktur mit (SuperClass, Interface, Parameter...) und wie, was genau...? Wir können nicht nachvollziehen. Sollten wir später die Objekte mal seine Strukturen ändern (was sich aber oft während einer Projekt passiert!), es sei neue Interface, mal neue Parameter (z. B. Object Adresse wird Param PLZ hinzugefügt...), dann ist die vorhandene Datenbank unlesbar. [/LIST] [LIST]Die Wrapper-Objects, die durch store() in die DB speichert, sollen also sich nicht beliebig seine Struktur ändern. Daher sollen sie möglich von Business-Schicht (Anwendungsschicht) fern und umgekehrt sollen business-Objects niemals direkt durch store(), delete()...mit DB kommunizieren lassen. Jede store(WrapperObject), retrieve(WO), delete(WO) in Wrapper-Schicht... sollen entsprechende Methoden store(BussinesObject), select(BO), delete(BO)... in Persistence-Schicht zuordnen und umgekehrt. Somit können wir bussiness-Objects und seine Struktur während einer Projekts oder später ändern und anpassen. [/LIST] [LIST]Also braucht mal schon gewisse Gedanke am Anfang einer Projekt, wie die Wrapper-Objects aufgebaut sind. [/LIST] [/QUOTE]

Verifizierung