Sinn DAOs

[Sanix]

Ich habe 18 verschiedene Views (Datenbank). Derzeit mache ich alles dynamisch. Dass heisst ich kriege ein ResultSet, formatiere die Daten so wie ich will. Diese formatierungen mache ich mit einer Methode für alle Views. Die Daten werden dann dargestellt.
Was ist jetzt der Vorteil, wenn ich 18 DAO - Klassen kreiere und nun alles mehr oder weniger hardcoden muss? Das bräuche dann 18 switch case Abfragen und bedeutet einiges mehr Arbeit.


Beispiel jetzt:

while(mehrDaten?)
 while(mehrSpalten!)
  SchreibeFeld();
loop

Nachher:

switch
case 1:
Dao.getStrasse()
Dao.getPLZ
case 2:
Dao.getStrasse()
Dao.getOrt

 

[AlArenal]

Schmu.. Du hättest doch nur eine DAO pro Domain-Klasse.

 

[RaoulDuke]

Beim DAO Pattern musst du dir erstmal klar machen das deine Einträge in der Datenbank Objekte repräsentieren. Wieviele Tabellen hast du denn?

 

[Sanix]

Ich hätte Daten aus 18 verschiedenen Views.

 

[SlaterB]

Es gibt immer Fälle bei denen das eine oder das andere besser ist.
Wenn alle Spalten Strings sind oder in einem bestimmten Typ umgewandelt werden können, dann kann man die wunderbar gemeinsam behandeln.

An anderer Stelle will man dagegen direkt auf eine Straße zugreifen, und dann ist getStrasse() eben schöner als
(String) getField(INDEX_STRASSE) oder was auch immer.

Da kann man nix pauschalisieren.

 

[AlArenal]

Stell dir vor du basust das Ganze als Lib für andere ENtwickler (was ja sogar zutreffen mag). Dann willst du die API, mit der diese arbeiten möglichst einfach und verständlich halten. Wildes Gecaste und die Übergabe von Keys, ... halte ich nicht für sehr 'freundlich'.

Denk nur an eins: Es ist ähnlich wie beim Hausbau. Was du am Fundament und an den tragenden Mauern verbockst, bekommst du später nur schwer oder gar nicht wieder gerade gezogen.

Mach die Gedanken, setze was um und schriebe dir Tests für die benötigten Funktionen. So bekommst du ein Gefühl dafür, wie es ist, deine Lib zu benutzen.

 

[Sanix]

Ich stelle keine Library zur verfügen. Die Klasse kann nur eine fertig formatierte Tabelle zurückgeben. Das Programm macht folgendes:
Liest view name aus einer xml. Setzt Zeile für Zeile in die Tabelle ein und formatiert die gewünschten Felder nach Vorgabe. Viele Felder kommen in mehreren Views vor, ein paar nicht.

 

[SlaterB]

Stell dir mal eine Datenbank vor, bei der ein User eine Tabelle Tiefgarage mit den Feldern Hoehe, Breite und Tiefe erstellt.

Findet sich in der Software der Datenbank ein Dao für diese Tabelle?
Nein, geht zwar gar nicht im Voraus, aber wird auch gar nicht benötigt,
der Datenbank ist alles egal, sie gibt nur Felder weiter.

Genauso wahrscheinlich deine Klasse, alles ist der gleiche Käse, hauptsache am Ende landet alles in einem String-Array zur Ausgabe.

Es ist völlig richtig, dass hier keine Daos benötigt werden, wozu?
Ob ein Feld nun Höhe oder Breite ist ist doch egal, was zählt ist, dass am Ende alle in einer Reihe stehen mit dem richtigen Inhalt.

Was völlig anderes ist dagegen eine Anwendung, die mit diesen Daten arbeiten.
Eine Anwendung mit 30 unterschiedlichen Logik-Prozessen, in denen cirka 150x getHöhe() aufgerufen wird.
(und z.B. nicht jedesmal der String in ein int gecastet werden soll)

Dort sind Daos nützlich, bei dir nicht, wo ist das Problem?

 

[AlArenal]

So lange du von Feldern und Tabellen, anstatt von Objekten sprichst, macht es auch keinen Sinn mit DAO loszulegen

 

[Sanix]

@AlArenal
Ich habe jetzt eine neue Anwendung alles mit DAOs gemacht. Der Schreibaufwand ist einfach einiges höher. Dafür kann ich später leichter was ändern.

@SlaterB
Danke für deine ausführliche Erklärung.

 

[AlArenal]

@sanix:

Ich bezog mich eher darauf, dass sich der Eindruck einschlich, dass jemand einfach nur wild Daten rumschaufeln will, dies aber nicht objektorientiert macht/machen muss, weil da keine Anwendung hintersteht, die OO ist. Also mehr ne Art DB-Konverter. Habe ich aber keine "richtigen" Daten-Objekte, brauch ich auch kein DAO, bzw. isses nicht wirklich sinnvoll sich mit dererlei Konzepten zu versuchen.
Wie der Versuch, alles mit dem Hammer zu reparieren...

 

[bronks]

Ich habe 18 verschiedene Views (Datenbank). Derzeit mache ich alles dynamisch. Dass heisst ich kriege ein ResultSet, formatiere die Daten so wie ich will. Diese formatierungen mache ich mit einer Methode für alle Views. Die Daten werden dann dargestellt ...

Moment! Ich lese das so, wie wenn Du eine App hättest, welche die Aufgabe hat, Daten aus der DB zu lesen und als Liste/Grafik auszugeben. Ist das so?

 

[SlaterB]

So schlimm muss es ja gar nicht mal sein.
Selbst in einer Anwendung, die hauptsächlich ganz konform auf Daos setzt, wäre es an manchen Stellen immer noch sinnvoll, Daten dynamisch zu behandeln.

Z.B. für Struts-Forms: 30x setFormElementX(dbObject.getX())

Wobei ich dabei ja die ganze Zeit eigentlich nicht vom Dao rede,
sondern vom TransferObject.

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

 

[Sanix]

Ich habe 18 verschiedene Views (Datenbank). Derzeit mache ich alles dynamisch. Dass heisst ich kriege ein ResultSet, formatiere die Daten so wie ich will. Diese formatierungen mache ich mit einer Methode für alle Views. Die Daten werden dann dargestellt ...

Moment! Ich lese das so, wie wenn Du eine App hättest, welche die Aufgabe hat, Daten aus der DB zu lesen und als Liste/Grafik auszugeben. Ist das so?

Ja genau. Einfach müssen ein paar Spalten spezielle Formatierungen aufweisen.

 

[bronks]

... Ja genau. Einfach müssen ein paar Spalten spezielle Formatierungen aufweisen.

Dabei würde ich das DAO lt. Spec (siehe Link den SlaterB gepostet hat) eher hinderlich finden und ihren eigentlichen Zweck würden diese dabei auch nicht erfüllen. Man muß auch beachten, wieviel Arbeitsspeicher die erzeugten Objekte brauchen und wie schnell deren Verarbeitung von sich geht.

Einfach über ein ResultSet loopen, formatieren und die Daten ausgeben ist eigentlich das günstigste was man machen kann, wenn man damit keine bestehende Architektur sprengt.