# Sinn DAOs



## Sanix (4. Sep 2006)

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
> ...


----------



## AlArenal (4. Sep 2006)

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


----------



## RaoulDuke (4. Sep 2006)

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 (14. Sep 2006)

Ich hätte Daten aus 18 verschiedenen Views.


----------



## SlaterB (14. Sep 2006)

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 (14. Sep 2006)

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 (14. Sep 2006)

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 (14. Sep 2006)

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 (14. Sep 2006)

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


----------



## Sanix (15. Sep 2006)

@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 (15. Sep 2006)

@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 (15. Sep 2006)

Sanix hat gesagt.:
			
		

> 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 (15. Sep 2006)

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 (15. Sep 2006)

bronks hat gesagt.:
			
		

> Sanix hat gesagt.:
> 
> 
> 
> ...



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


----------



## bronks (15. Sep 2006)

Sanix hat gesagt.:
			
		

> ... 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.


----------

