Discussion:
[OOD] Klassen zur Datenhaltung aus DB.
(zu alt für eine Antwort)
Harald Stowasser
2005-06-14 12:48:47 UTC
Permalink
Hallo liebe dclj Leser,

wir sind gerade dabei ein größeres Web-Projekt aufzuziehen. Jetzt mach
ich mir Gedanken über die Klassen welche die Daten innerhalb der DB
repräsentieren sollen.

Ich habe mir dazu ein paar Gedanken gemacht. Und ein paar Entwurfsmuster
erdacht. Ich bin mir jedoch noch Unschlüssig welches ich verwenden soll.


1. Database-Proxy
Jede Eigenschaft resultiert in einem Datenbank-zugriff.
Vorteil :Synchrone Kommunikation.
Nachteil:z.B. keine Temporären Objekte möglich. Sehr viel Traffic.

2. Komposition Dataholder.
Die Felder der Datenbank werden in einer HashMap festgehalten, können
somit leicht ausgelesen und gesetzt werden. Das laden und speichern der
Daten ist ziemlich einfach.
Vorteil: Sehr einfache Klasse.
Nachteil: Keine Kapselung, Fehleranfällig. Nicht typsicher.

3. Simple Dataholder.
Alle Eigenschaften als öffentliche Felder ausgelegt. Einfache
Load/Save-Methoden.
Vorteil: noch einfach zu programmieren, kann z.B. auch in der Session
gehalten werden. Row-Locking oder Optimistic-Locking möglich.
Nachteil: Keine Kapselung.

4. Komplex Dataholder.
Alle Eigenschaften gekapselt. Fast nur get-Methoden. Hash & und equal
Methoden. Eventuell auch serialize und copy.
Vorteil: Typsicher, gekapselt, Vergleich möglich. Row-Locking oder
Optimistic-Locking möglich. Kann in Kompositionen gut eingesetzt werden.
Nachteil viel Programmieraufwand.

5. Datamachine.
wie 4, jedoch noch Methoden zur Darstellung im Web. Wie Formular zum
ändern/neuerstellen. HTML-Vorschau...
Vorteil: Wie bei 4. Alles an einem Platz.
Nachteil:Noch mehr Programmieraufwand.



Die meisten Beispiele die ich gesehen hab, greifen direkt auf die DB zu.
Das ist jedoch bei unserem Projekt IMHO nicht mehr praktikabel. Weil es
wirklich groß wird.

Wie regelt Ihr die Repräsentation von Daten in eurem Projekt?


Danke für eure Meinungen.



P.S. Beans möchte ich nicht einsetzen, da die mir nur sinnvoll
erscheinen, wenn der Designer nicht Programmieren kann. Was bei uns
nicht der Fall ist.
Ingo R. Homann
2005-06-14 13:17:12 UTC
Permalink
Hi, Harald
Post by Harald Stowasser
1. Database-Proxy
Jede Eigenschaft resultiert in einem Datenbank-zugriff.
Vorteil :Synchrone Kommunikation.
Nachteil:z.B. keine Temporären Objekte möglich. Sehr viel Traffic.
Der Traffic kann da IMHO zu einem existenziellen Problem werden!
Schlechte Idee.
Post by Harald Stowasser
2. Komposition Dataholder.
Die Felder der Datenbank werden in einer HashMap festgehalten, können
somit leicht ausgelesen und gesetzt werden. Das laden und speichern der
Daten ist ziemlich einfach.
Vorteil: Sehr einfache Klasse.
Nachteil: Keine Kapselung, Fehleranfällig. Nicht typsicher.
Äh, Du meinst, eine Datenbank-Tabelle korrespondiert direkt mit einer
HashMap? Da überwiegen die Nachteile IMHO sehr stark! Da kannst Du auch
gleich auf dem java.sql.ResultSet hantieren...
Post by Harald Stowasser
3. Simple Dataholder.
Alle Eigenschaften als öffentliche Felder ausgelegt. Einfache
Load/Save-Methoden.
Vorteil: noch einfach zu programmieren, kann z.B. auch in der Session
gehalten werden. Row-Locking oder Optimistic-Locking möglich.
Nachteil: Keine Kapselung.
Für einfache Anwendungen IMHO gut geeignet.
Post by Harald Stowasser
4. Komplex Dataholder.
Alle Eigenschaften gekapselt. Fast nur get-Methoden. Hash & und equal
Methoden. Eventuell auch serialize und copy.
Vorteil: Typsicher, gekapselt, Vergleich möglich. Row-Locking oder
Optimistic-Locking möglich. Kann in Kompositionen gut eingesetzt werden.
Nachteil viel Programmieraufwand.
Auch wenn einige mich dafür steinigen werden: Diese Kapselung halte ich
nicht für sinnvoll. Wenn Du setter hast, können die Felder also auch
verändert werden. Aber was willst Du in den settern noch machen? Die
Daten auch gleich in die DB schreiben? Das ist IMHO eine schlechte Idee,
weil Du dann evtl. x Schreibzugriffe hast, wo einer reichen würde (mal
abgesehen davon, dass unique indices dabei failen könnten). Und wenn Du
keine setter hast, kannst Du auch Variante 3 nehmen und final-Variablen
verwenden.

Der Ansatz ist IMHO nix halbes und nix ganzes. Dann lieber 3.
Post by Harald Stowasser
5. Datamachine.
wie 4, jedoch noch Methoden zur Darstellung im Web. Wie Formular zum
ändern/neuerstellen. HTML-Vorschau...
Vorteil: Wie bei 4. Alles an einem Platz.
Nachteil:Noch mehr Programmieraufwand.
Der Ansatz gefällt mir. Die Methoden zur Darstellung im Web sind
allerdings kompliziert bzw. müssen hochgradig konfigurierbar sein:
Manchmal hast Du zusammengesetzte Daten, wie sagen wir:

Person->Telefonnummer
Telefonnummer: Vorwahl+Nummer+Durchwahl

Die sollen dann alle im Formular für "Person" erscheinen.

Manchmal sollen aber die von "Person" referenzierten Daten nicht im
selben Formular mit bearbeitet werden, wie z.B. "Person->Kind".

Rein "strukturell" handelt es sich um dieselben Fälle: Ein "Objekt"
referenziert ein anderes. Trotzdem müssen sie im Formular
unterschiedlich gehandhabt werden.
Post by Harald Stowasser
Die meisten Beispiele die ich gesehen hab, greifen direkt auf die DB zu.
Das ist jedoch bei unserem Projekt IMHO nicht mehr praktikabel. Weil es
wirklich groß wird.
ACK.
Post by Harald Stowasser
Wie regelt Ihr die Repräsentation von Daten in eurem Projekt?
Wir verwenden Ansatz 5 (und sind damit ganz glücklich). Allerdings ist
dar Ansatz so offen gehalten, dass man ihn auch als Ansatz 3 bzw. 4
verwenden kann, falls die "Datamachine" mal nicht die Funktionalität
hergibt, die man gerade braucht.
Post by Harald Stowasser
Danke für eure Meinungen.
Ciao,
Ingo

PS: Ist der Begriff "Datamachine" was offizielles oder von dir
ausgedacht? Wikipedia kennt den nicht, und was google dazu ausspuckt...
Christoph Dahlen
2005-06-14 13:44:48 UTC
Permalink
Post by Ingo R. Homann
Post by Harald Stowasser
4. Komplex Dataholder.
Alle Eigenschaften gekapselt. Fast nur get-Methoden. Hash & und equal
Methoden. Eventuell auch serialize und copy.
Vorteil: Typsicher, gekapselt, Vergleich möglich. Row-Locking oder
Optimistic-Locking möglich. Kann in Kompositionen gut eingesetzt werden.
Nachteil viel Programmieraufwand.
5. Datamachine.
wie 4, jedoch noch Methoden zur Darstellung im Web. Wie Formular zum
ändern/neuerstellen. HTML-Vorschau...
Vorteil: Wie bei 4. Alles an einem Platz.
Nachteil:Noch mehr Programmieraufwand.
Der Ansatz gefällt mir.
Mit überhaupt nicht. Zum einen würde ich, seit es passable O/R-Mapper im
OpenSource Bereich (Hibernate, Apache OJB) nur noch selten eine
Eigenimplementierung vorschlagen, zum anderen schafft die Programmierung
der Darstellung (für das Web-Formular) in dem darzustellenden View (der
Klasse) nur Probleme, z.B. bei Lokalisierung oder alternativen
Wiedergabe-Formaten wie XML oder z.B. Text.

Dieser Teil ist eindeutig Aufgabe der Ansicht, im Kontext einer
Web-Applikation üblicherweise in JSP(X) realisiert.

Christoph
Christoph Dahlen
2005-06-14 13:53:57 UTC
Permalink
Post by Christoph Dahlen
zum anderen schafft die Programmierung
der Darstellung (für das Web-Formular) in dem darzustellenden View (der
Klasse) nur Probleme, z.B. bei Lokalisierung oder alternativen
Wiedergabe-Formaten wie XML oder z.B. Text.
Oh Mann, soll natürlich heissen, von der Programmierung der Darstellung
im Modell ist abzuraten.

Ist halt noch früh .. glaub ich.

Christoph
Ingo R. Homann
2005-06-14 14:19:48 UTC
Permalink
Hi,
Post by Christoph Dahlen
Post by Ingo R. Homann
Post by Harald Stowasser
5. Datamachine.
wie 4, jedoch noch Methoden zur Darstellung im Web. Wie Formular zum
ändern/neuerstellen. HTML-Vorschau...
Vorteil: Wie bei 4. Alles an einem Platz.
Nachteil:Noch mehr Programmieraufwand.
Der Ansatz gefällt mir.
Mit überhaupt nicht. Zum einen würde ich, seit es passable O/R-Mapper im
OpenSource Bereich (Hibernate, Apache OJB) nur noch selten eine
Eigenimplementierung vorschlagen,
Ich schrieb ja nicht, dass man das unbedingt selbst implementieren soll.

(Obwohl wir hier tatsächlich eine Eigenimplementierung verwenden, deren
Ursprünge allerdings AFAIK in die pre-"Hibernate-et-al"-Ära hineinreichen.)
Post by Christoph Dahlen
zum anderen schafft die Programmierung
der Darstellung (für das Web-Formular) in dem darzustellenden View (der
Klasse) nur Probleme, z.B. bei Lokalisierung oder alternativen
Wiedergabe-Formaten wie XML oder z.B. Text.
Gerade im Bereich der Lokalisierung haben wir hier gute Erfahrungen
damit gemacht. Die Java-Bordmittel der Lokalisierung reichen leider
nicht immer aus - und dann ist man froh, wenn man leicht auf die Daten
aus der Datenbank zurückgreifen kann (auch wenn es natürlich schöner
wäre, wenn man darauf verzichten könnte).

Genauso ist die Trennung zwischen View und Model eine an sich zwar
löbliche Sache. Wenn man seine Daten aber - wie hier - z.B. zunächst
hauptsächlich in HTML darstellen möchte, später dann aber auch andere
Formate benötigt, kommt man um eine Implementierung der entsprechenden
Teile (für das neue Format!) nicht drumrum. Da verschiedene Views
allerdings auch gänzlich unterschiedliche Eigenschaften haben, kann man
das ohnehin nicht in einem Aufwasch erledigen. Wenn man seine Daten
später mal in XML oder Text ausgeben möchte, und ursprünglich HTML
verwendet hat, mag das noch gehen (da reicht dann fast schon das
triviale Austauschen der Tags). Aber stell mal die Daten z.B. in PDF da,
oder in einer JTable. Da ist ohnehin viel manuelle Anpassung nötig.
Selbst "ähnliche" Formate (im Sinne des beabsichtigten, seitenbasierten
Ausgabemediums) wie PDF und RTF/DOC sind offensichtlich so
unterschiedlich bzw. komplex, dass es (noch) keine vernünftigen Packete
gibt, die beides aus einer gemeinsamen Datenbasis ausgeben können.

Ciao,
Ingo
Christoph Dahlen
2005-06-14 14:48:14 UTC
Permalink
Post by Ingo R. Homann
Gerade im Bereich der Lokalisierung haben wir hier gute Erfahrungen
damit gemacht. Die Java-Bordmittel der Lokalisierung reichen leider
nicht immer aus - und dann ist man froh, wenn man leicht auf die Daten
aus der Datenbank zurückgreifen kann (auch wenn es natürlich schöner
wäre, wenn man darauf verzichten könnte).
Mich würde mal interessieren, was Dir da fehlt, ich persönlich habe mit
ResourceBundles und den Formatierungs-Helfern aus java.text bisher nur
gute Erfahrungen sammeln können.
Post by Ingo R. Homann
Genauso ist die Trennung zwischen View und Model eine an sich zwar
löbliche Sache.
Nicht nur das, sie ist überlebenswichtig ;)
Post by Ingo R. Homann
Da verschiedene Views
allerdings auch gänzlich unterschiedliche Eigenschaften haben, kann man
das ohnehin nicht in einem Aufwasch erledigen.
Möglicherweise hat Dich mein Tippfehler ja in die falsche Richtung
geleitet, aber gerade die obige Aussage untermauert doch die allgemein
akzeptierte Trennung von Modell und View.

Das Modell transportiert nur _was_ als Information dargestellt werden
kann, der View kümmerst sich darum _wie_ es dargestellt wird. Da muß
z.B. noch nicht mal ein Wechsel von HTML nach XML anstehen, es reicht
doch auch schon, wenn ich z.B. einen Artikel (Titel, Anriss, Text, Datum
etc.) nicht für Browser wie den IE oder Firefox, sondern komprimierter
für PDA Browser darstellen möchte: 1 Bean (Modell) -> 2 Views

Christoph
Ingo R. Homann
2005-06-14 15:01:16 UTC
Permalink
Hi,
Post by Christoph Dahlen
Post by Ingo R. Homann
Gerade im Bereich der Lokalisierung haben wir hier gute Erfahrungen
damit gemacht. Die Java-Bordmittel der Lokalisierung reichen leider
nicht immer aus - und dann ist man froh, wenn man leicht auf die Daten
aus der Datenbank zurückgreifen kann (auch wenn es natürlich schöner
wäre, wenn man darauf verzichten könnte).
Mich würde mal interessieren, was Dir da fehlt, ich persönlich habe mit
ResourceBundles und den Formatierungs-Helfern aus java.text bisher nur
gute Erfahrungen sammeln können.
Hinbekommen tut man sicher alles *irgendwie* mit ResourceBundles. Ich
stand hier mal vor dem Problem, dass bestimmte "Texte"/"Labels" vom
Kunden abhingen (welches Bundesland?). Andere (es geht um Wahlsoftware)
hingen vom aktuellen Wahltyp (Landtagswahl, Bundestagswahl, ...?) ab.
Wieder andere hingen von der Kombination von beidem ab. Bei noch anderen
hing es davon ab, ob der Kunde eine Gemeinde, eine Stadt, ein Kreis oder
eine Kreisfreie Stadt ist. Die meisten Labels sind aber identisch oder
hängen nur von einem Parameter ab. Wie soll ich das (sinnvoll) über
ResourceBundels lösen (ohne ein RB für jede denkbare Kombination zu
pflegen und jede Menge Redundanzen zu haben)?
Post by Christoph Dahlen
Post by Ingo R. Homann
Da verschiedene Views allerdings auch gänzlich unterschiedliche
Eigenschaften haben, kann man das ohnehin nicht in einem Aufwasch
erledigen.
Möglicherweise hat Dich mein Tippfehler ja in die falsche Richtung
geleitet, aber gerade die obige Aussage untermauert doch die allgemein
akzeptierte Trennung von Modell und View.
Das Modell transportiert nur _was_ als Information dargestellt werden
kann, der View kümmerst sich darum _wie_ es dargestellt wird.
Naja, der View kümmert sich eben auch darum, _was_ dargestellt wird. Wie
Post by Christoph Dahlen
...es reicht doch auch schon, wenn ich z.B. einen Artikel ...
nicht für Browser ..., sondern komprimierter
für PDA Browser darstellen möchte...
Ich hatte Dich (offensichtlich fälschlicherweise) so verstanden, dass
der View nur noch rudimentäre Dinge machen soll...

Ciao,
Ingo
Harald Stowasser
2005-06-14 14:32:07 UTC
Permalink
Post by Ingo R. Homann
Post by Harald Stowasser
4. Komplex Dataholder.
Alle Eigenschaften gekapselt. Fast nur get-Methoden. Hash & und equal
Methoden. Eventuell auch serialize und copy.
Vorteil: Typsicher, gekapselt, Vergleich möglich. Row-Locking oder
Optimistic-Locking möglich. Kann in Kompositionen gut eingesetzt werden.
Nachteil viel Programmieraufwand.
Auch wenn einige mich dafür steinigen werden: Diese Kapselung halte ich
nicht für sinnvoll. Wenn Du setter hast, können die Felder also auch
verändert werden. Aber was willst Du in den settern noch machen?
Eigentlich ist der hier mein Favorit. In den settern kann man z.B. ein
"changed"-Flag setzen, um zu wissen ob man z.B. den Hash neu generieren
muss. Oder um festzustellen ob der User die Daten im Formular wirklich
geändert hat. -> Dann kann man sich ja das Update in die DB sparen.
Post by Ingo R. Homann
PS: Ist der Begriff "Datamachine" was offizielles oder von dir
ausgedacht? Wikipedia kennt den nicht, und was google dazu ausspuckt...
Da ich in meiner Literatur gar keine Patterns für so was gefunden hab,
hab ich das Zeug einfach irgendwie benannt
Vielleicht ist es einfach zu Trivial?
Datamachine fand ich ganz treffend ;-)
Ingo R. Homann
2005-06-14 14:45:36 UTC
Permalink
Hi,
Post by Harald Stowasser
Post by Ingo R. Homann
Post by Harald Stowasser
4. Komplex Dataholder.
Alle Eigenschaften gekapselt. Fast nur get-Methoden. Hash & und equal
Methoden. Eventuell auch serialize und copy.
Vorteil: Typsicher, gekapselt, Vergleich möglich. Row-Locking oder
Optimistic-Locking möglich. Kann in Kompositionen gut eingesetzt werden.
Nachteil viel Programmieraufwand.
Auch wenn einige mich dafür steinigen werden: Diese Kapselung halte ich
nicht für sinnvoll. Wenn Du setter hast, können die Felder also auch
verändert werden. Aber was willst Du in den settern noch machen?
Eigentlich ist der hier mein Favorit. In den settern kann man z.B. ein
"changed"-Flag setzen, um zu wissen ob man z.B. den Hash neu generieren
muss.
Bei mutable-Objekten sollte man mit HashCodes ohnehin aufpassen: Wenn Du
die in eine HashMap packst und dann den Wert veränderst, wird das Objekt
nicht wiedergefunden!

(Für andere Dinge kann ein change-flag allerdings tatsächlich sinnvoll
sein.)

Meinetwegen ist dieser Ansatz OK, obwohl ich nach wie vor denke, dass
seine Vorteile gegenüber 3 gering sind und der Aufwand aber höher ist.

Trotzdem brauchst Du dann noch eine View-Komponente, die die
verschiedenen Dataholder darstellen/bearbeiten kann. Dieser View
benötigt (wie ich in meinem ersten Posting geschrieben habe) noch einige
Informationen, die sinnvollerweise im Model abzulegen sind...
Post by Harald Stowasser
Oder um festzustellen ob der User die Daten im Formular wirklich
geändert hat. -> Dann kann man sich ja das Update in die DB sparen.
Naja, OK, man spart *in seltenen Fällen* (wenn der User nichts ändert
aber trotzdem auf "Save" clickt) einen Datenbank-Zugriff. Für die
meisten Applikationen dürfte dieser Fall nicht all zu wichtig sein...
Post by Harald Stowasser
Post by Ingo R. Homann
PS: Ist der Begriff "Datamachine" was offizielles oder von dir
ausgedacht? Wikipedia kennt den nicht, und was google dazu ausspuckt...
Da ich in meiner Literatur gar keine Patterns für so was gefunden hab,
hab ich das Zeug einfach irgendwie benannt
Vielleicht ist es einfach zu Trivial?
IMHO ist es alles andere als trivial! Für verschiedene Anwendungsfälle
sind die verschiedenen Ansätze unterschiedlich gut geeignet. Oft ist
sicher auch eine Mischung der Ansätze sinnvoll.

Ich erwarte jedenfalls noch einen langen Thread!

Ciao,
Ingo
Alfred
2005-06-15 07:41:06 UTC
Permalink
Post by Harald Stowasser
Hallo liebe dclj Leser,
wir sind gerade dabei ein größeres Web-Projekt aufzuziehen. Jetzt mach
ich mir Gedanken über die Klassen welche die Daten innerhalb der DB
repräsentieren sollen.
Ich habe mir dazu ein paar Gedanken gemacht. Und ein paar Entwurfsmuster
erdacht. Ich bin mir jedoch noch Unschlüssig welches ich verwenden soll.
1. Database-Proxy
...nein
2. Komposition Dataholder.
...nein
3. Simple Dataholder.
...nein
4. Komplex Dataholder.
Alle Eigenschaften gekapselt. Fast nur get-Methoden. Hash & und equal
Methoden. Eventuell auch serialize und copy.
Vorteil: Typsicher, gekapselt, Vergleich möglich. Row-Locking oder
Optimistic-Locking möglich. Kann in Kompositionen gut eingesetzt werden.
Nachteil viel Programmieraufwand.
Aber wesentlich vernünftiger als 1-3
Post by Harald Stowasser
5. Datamachine.
wie 4, jedoch noch Methoden zur Darstellung im Web.
Das gehört nicht in deine Datenträger, sondern höchstens
in Form-Beans.
Post by Harald Stowasser
Die meisten Beispiele die ich gesehen hab, greifen direkt auf die DB zu.
Richtige Entscheidung dies nicht zu praktizieren.
Post by Harald Stowasser
P.S. Beans möchte ich nicht einsetzen, da die mir nur sinnvoll
erscheinen, wenn der Designer nicht Programmieren kann. Was bei uns
nicht der Fall ist.
Ist das nur ein Spruch aus Unkenntnis heraus oder meinst du das ernst?
Diese Behauptung trifft eher auf Programmierer zu, die aus einer JSP
heraus direkt auf Datenbanken zugreifen und dabei noch nicht mal
einen Pool benutzen.

Aber schau dir doch mal Hibernate (für das Datenhandling) und Struts
(für die Darstellung im Web) an. Das sollte dir weiter helfen.

Trotzdem - was spricht gegen "klassische" J2EE-Technologie?
Oder kombiniere JBoss, Hibernate und Struts miteinander.

Alfred

Lesen Sie weiter auf narkive:
Loading...