# Entwurf 3-Schichten-Architektur



## holley (9. Jan 2004)

Hallo,

Wie trenne ich sauber(!) die Schichten 2 Geschäftslogik und 3 Datenbank?

.anwendung.ui   Schicht1
.anwendung.lg   Schicht2
.anwendung.db   Schicht3

Wenn es nun z.B. im Packet 'lg' eine Klasse 'Umsatz' mit der Methode 'get' gibt, wie interagiert diese dann mit der Methode 'query' der Klasse 'DB' aus dem Packet 'db'?
Soll 'query' ein ResultSet an die aufrufende Methode zurückgegeben? Habe ich dann noch ein saubere Trennung? 
Wenn ich das benötigte Select-Statement in 'Umsatz.get()' definiere, bin ich dann noch DB unabhängig (SQL-Syntax von DB's nicht immer identisch)?

Also ich komme hier gedanklich nicht weiter und würde mich über eine Diskussion freuen.
Es ist zwar keine direkte Java-Problematk, ich hoffe aber das ich hier trotzdem Hilfe finde.

mfg Michael


----------



## HeyMan (9. Jan 2004)

hi.
schon mal was von schnittstellen/interfaces gehört? das wär/ist  wohl immer die beste Möglichkeit verschiedene Ebenen zu erstellen. An deiner Stelle wür dich ein Interface im package db implementieren. Mit dem kannst du dann anstellen was du willt. toll, gelle. Und übergibbloss keine ResultSets oder so. Pack den scheiss in Vectoren oder Hashes. Dann ist es sauberer getrennt ausserdem ist es performanter, da diese Objekte im Stack als 64 Bit -er liegen und so schneller verarbeitt werden können (..da bin ich mir aber nicht ganz sicher).
Gruß
HeyMan


----------



## René Link (10. Jan 2004)

Hey HeyMan,

also ich muss dir leider ein bisschen wiedersprechen. Kennst du eigentlich den Unterschied
zwischen den ResultSets und deiner Lösung alles in Vectoren zu packen?

Bei einem ResultSet hast du die Daten der Abfrage nicht auf deinem Rechner. Ein ResultSet
repräsentiert nur einen Cursor auf der Datenbank. Das heißt, dass sich die Ergebnismenge auf
der Datenbank befindet und nicht im Arbeitsspeicher des Clients. Waraum soetwas?
Ganz einfach. Eine Datenbank ist dafür ausgelegt mit großen Datenmengen umzugehen. Außerdem
implementiert diese effiziente Algorithmen um auch mit ausgelagerten Daten (auf der Festplatte) zurechtzukommen.
Bei einer Abfrage kannst du ja nie wissen wie groß die Ergebnismenge wird und alles in den Client zu kopieren
ist schlichtweg Unsinn. Bei winzigen Applikationen mag das wohl gehen, aber keine ernstgemeinte DB-Anwendung
wird soetwas machen. Wenn dich soetwas interessiert und du es ganau wissen willst empfehle ich dir
das Buch  http://www.computer-link.de/view.php?paragraphID=70


----------



## Bastie (30. Jan 2004)

Nun wie schon erwähnt sind Interfaces die saubere Lösung - am besten Verbunden mit einer Factory die nur Interfacetypen zurückgibt.

Um zu testen, ob du die Architektur sauber hast - leg doch die DB Schicht einfach auf einen Server!


----------

