# Swing Anwendung mit DB



## Capasso (2. Okt 2008)

Hallo,

ich möchte eine Anwednung programmieren die ihre Daten aus einer Datenbank bezieht.
Die Datenbank soll mit der Anwendung ausgelierfert werden.

Aber ich bin mir nicht sicher welche Vorgehensweise die Beste ist.

Ich möchte das Projekt nach MVC aufteilen.

Nun stehe ich vor folgenden der Frage:
Wie handhabe ich das mit der Datenbankanbindung und Persitenz?
Selber machen, Framework (wenn ja welches und warum) oder ganz was anderes.

Gruß
Cap
Ps.: Ein link zu einem Tutorial wäre dann auch nicht schelcht


----------



## foobar (2. Okt 2008)

Da gibt es viele Möglichkeiten. Wenn du eine neue Anwendunng entwickelst lohnt sich auf jeden Fall ein ORM-Tool wie Hibernate. Als DB kann ich dir Apache Derby empfehlen.
Du kannst das ganze aber auch mit iBatis, Spring Jdbc oder reinem Sql implementieren. Von purem Sql kann ich dir nur abraten, Spring JDBC ist da schon eine sehr große Hilfe.
DAO-Pattern ist in jedem Fall ein Muß: http://de.wikipedia.org/wiki/Data_Access_Object


----------



## Capasso (6. Okt 2008)

hast du zufällig nen gutes Tutorial zu Hibernate oder Spring und DAO. (am besten Deutsch   )


----------



## maki (6. Okt 2008)

DAOs sind doch überflüssig mit JPA.


----------



## L-ectron-X (6. Okt 2008)

Warum?


----------



## maki (6. Okt 2008)

Die üblichen (und primitiven) CRUD Operationen werden schon vom EntityManager bereitgestellt, dafür hat man früher DAOs genommen.

Für Funktionen auf einer höheren Abstraktionensebene kann man sich sog. Repositories schreiben, ist auch besser imho:
1. sonst endet in den DAOs einerseits wieder Businesslogik
2. oder man greift auf diese primitiven DAOs Operationen direkt aus hogh-level Abstraktionen zu, wie zB. Domänenobjekte oder gar EJBs zu, auch nicht schön.


----------



## foobar (6. Okt 2008)

maki hat gesagt.:
			
		

> DAOs sind doch überflüssig mit JPA.



Mit Hibernate verwende ich auch ein GenericDAO, um alle Queries an einer Stelle zu sammeln. Wie machst du das?


----------



## L-ectron-X (6. Okt 2008)

maki hat gesagt.:
			
		

> Die üblichen (und primitiven) CRUD Operationen werden schon vom EntityManager bereitgestellt, dafür hat man früher DAOs genommen.


Ich hab ganz selten mit Datenbanken zu tun. Daher sagt mir _EntityManager_ erst mal gar nichts. ???:L 
Kannst du mal etwas mehr darüber verraten?


----------



## tfa (6. Okt 2008)

Ich verwende die JPA-Implemtierung Hibernate (genauer gesagt ein HibernateTemplate über Spring) und habe trotzdem DAOs. Nichts spricht dagegen, hier eine Abstraktionsebene zu kapseln. Zwar delegieren die meisten Methoden nur an das Template, aber einige unübliche, nicht-primitive Operationen sind trotzdem vorhanden. Die kommen dann in konkrete DAO-Implementierungen pro Fachklasse, der Rest steht in einem GenericDAO.
Außerdem wird das Transaktionsmanagement (unter anderem) in den DAOs geregelt.


----------



## foobar (6. Okt 2008)

> Für Funktionen auf einer höheren Abstraktionensebene kann man sich sog. Repositories schreiben, ist auch besser imho:


Wie sieht das dann aus?

Mit dem EntityManager habe ich noch nie gearbeitet, daher nutze ich immer DAOs.


----------



## maki (6. Okt 2008)

Wie gesagt, der EntityManager bietet das schon, da werden DAOs im Hintergrund soz. erzeugt und vom Nutzer versteckt (abstrahiert).

Für Funktionen die über die Standard CRUD Operationen hinausgehen, sollte man sich sog. Repositories schreiben.

Anders als DAOs sind Repositories high-level Abstraktionen, da werden Methoden angeboten die von Domänenobjekten direkt genutzt werden, also mit fachlichem Bezug.

Diese Methoden in DAOs zu packen hat oft dazu geführt, dass in den DAOs Businesslogik enthalten ist... oder man hat an einer Stelle für komplexere Operationen mehrere DAOs benutzt, oft gesehen in EJBs 2.1, auch nicht schön, da DAOs eher primitiver Natur sind, passt nicht wirklich zur OO.


----------



## maki (6. Okt 2008)

L-ectron-X hat gesagt.:
			
		

> maki hat gesagt.:
> 
> 
> 
> ...


Der EntityManager ist die Neuerung in JPA (abgesehen von den annos), Dinge wie eine Entities finden, persistieren, updaten, löschen, NamedQueries ausführen etc. werden alle von ihm übernommen, eben das was früher die DAOs gemacht haben.

http://java.sun.com/javaee/5/docs/api/javax/persistence/EntityManager.html


----------



## L-ectron-X (6. Okt 2008)

Da du einen Link zum J2EE-API gepostet hast, muss ich davon ausgehen, dass mir die Klasse nicht für Desktop-Applikationen zur Verfügung steht?


----------



## maki (6. Okt 2008)

JPA gibt es für sowohl JEE als auch die SE 
Einer der Gründe warum JPA nicht teil des EJB3 Standards sondern ein eigener Standard geworden ist, ist dass man sie so auch ohne EJB3 einsetzen kann.


----------



## Capasso (6. Okt 2008)

Ich will euch ja nicht bei der Diskussion stören, aber ...



> hast du zufällig nen gutes Tutorial zu Hibernate oder Spring und DAO. (am besten Deutsch  )


----------



## foobar (6. Okt 2008)

Capasso hat gesagt.:
			
		

> Ich will euch ja nicht bei der Diskussion stören, aber ...
> 
> 
> 
> > hast du zufällig nen gutes Tutorial zu Hibernate oder Spring und DAO. (am besten Deutsch  )



Ein Tutorial habe ich jetzt nicht griffbereit aber es gibt ein paar gute Bücher zu dem Thema:

http://www.amazon.de/Java-Persisten...=sr_1_3?ie=UTF8&s=books&qid=1223289926&sr=8-3
http://www.amazon.de/Hibernate-Prax...=sr_1_2?ie=UTF8&s=books&qid=1223289926&sr=8-2
http://www.amazon.de/Spring-in-Acti...ie=UTF8&s=books-intl-de&qid=1223289971&sr=8-1


----------



## Capasso (6. Okt 2008)

Danke, aber Bücherkaufen kommt leider momentan nicht in Frage.


----------



## maki (6. Okt 2008)

Dann halt eben die Online Ressourcen:
http://www.springframework.org/documentation


----------



## Capasso (6. Okt 2008)

Da wären wir wieder bei einem Problem.

Die meisten Tutorials nd Anleitung gehen gezielt auf Webanwendungen ein. 
Ich suche nach einer Anleitung für den gebrauch mit eine DesktopApplikation


----------



## foobar (6. Okt 2008)

Hibernate in eine Desktopanwendung zu integrieren ist aber wesentlich einfacher als bei einer verteilten Anwendung, da man hier mit einer einzigen Session arbeiten kann.
Wenn du die Hibernatebasics drauf hast, kannste auch eine Desktopanwendung damit entwickeln.


----------



## foobar (7. Okt 2008)

@maki Wie sieht denn so ein Repository aus und was genau kommt da rein? Vermischt man damit nicht auch Persistenz und Geschäftslogik?

Die einzige Geschäftslogik die man in GenericDAOs hat ist z.b. so eine Art Trigger (wenn in Tabelle xyz etwas eingefügt wird, berechne dies und das). Das finde ich aber nicht so trageisch, weil das alles durch Hibernate ja unabhängig von der DB ist.


----------



## maki (7. Okt 2008)

Die Repositories gehören zur Domäne und damit zur Geschäftslogik, für jede Entity ein Repository bzw. so wie man sie braucht 

Die Repositories sind die einzigen Stellen der Anwendung, in denen DAOs genutzt werden, sie bilden die Schnittstelle zwischen Business Tier und Integration Tier.

Die Methoden die sie anbieten sind "high-level", also auf demselben Niveau wie die Domänenobjekte welche die Repositories nutzen, dadurch trennt man elegant zwischen Persistenz und Domäne.

Persönlich halte ich nicht viel davon, Domainobjekte direkt auf DAOs zugreifen zu lassen, es gibt da soz. einen Bruch in der Abstraktionsebene: 
Domainobjekt -> high level, fachlich
DAO -> low level, CRUD Operationen auf eine DB, oft ein DAO pro Tabelle, hat eigentlich nix mit Geschäftslogik zu tun, sondern mit Implementierungsdetails.

Macht man die DAOs high level mischt man dort Geschäftslogik mit Persistenzlogik.

Die Alternative ist, die DAOs aus Services(SessionBeans etc.) zu nutzen, nicht sehr OO imho, spätestens wenn ein UseCase mehrere DAOs braucht merkt man wie unschön das eigentlich ist...

Mit Repositories können die Entitäten(Domänenobjekte) selbst andere Entitäten finden/speichern/löschen etc, ohne Details zu kennen, denn diese sind ja in den Repositories gekapselt.
Typische Methoden für ein Rep. wären findById(..), findByCriteria(..), store(..) bzw. save(..), delete und dann noch die zus. Businessmethoden, so wie sie gebraucht werden.

Im Prinzip sind Repositories DAOs mit high level Methoden und stellen dadurch eine zus. Abstraktion zwischen Domäne und echten DAOs dar.  Diese "Schicht" ist eigentlich sehr dünn, Clientseitig werden eben wie gesagt nur high-level Methoden angeboten, intern werden DAOs genutzt um diese umzusetzen.

Repositories sind natürlich zusätzlicher Aufwand (so wie jede Abstraktion), aber wenn man sich die DAOs dank dem JPA EntityManager sparen kann, tut man gut daran sie einzusezten.

Sie haben viele Vorteile, von der angesprochen Trennung der verschiedenen Abstraktionsebenen bieten sie sehr einfach die Möglichkeit, Unittests zu schreiben, brauche ja bloss ein Mock-Repository anstatt einer echten DB Anbindung um meine Domäne zu testen 

Bin durch das Buch "POJOs in Action" darauf gekommen, die eigentliche Idee ist aber älter und wird schon im Buch "Domain Driven Design" von Eric Evans besprochen.


----------



## Performance Geek (8. Okt 2008)

Guter Artikel zum Thema Hibernate Performance 

www.codecentric.de/_resources/pdf/hibernate_performance_tuning.pdf

Dort gibt es auch weitere Informationen zu SpringFramework, z.B. Spring Web Flow, etc.


----------



## byte (8. Okt 2008)

Ich sehe nicht so richtig, welchen Vorteil Repositories bringen sollen gegenüber der (herrkömmlichen) Trennung in Services + DAOs. Ich stimme Dir zwar insofern zu, dass Services den OO-Gedanken verletzen, da dort Business Logik sozusagen vom Domänenmodell entkoppelt ist. Aber hast Du das gleiche Problem bei den Repositories nicht auch, wenn dort Business Logik implementiert wird?

Darüber hinaus denke ich, dass selbst mit EntityManager DAOs nicht obsolet sind. Irgendwo möchtest Du doch deine Transaktionen im Idealfall deskriptiv konfigurieren. Und in der Praxis gehen die DB-Abfragen doch eigentlich immer über einfache CRUD Befehle hinaus. Man hat doch eigentlich immer domänenspezifische Abfragen zu tätigen, daher macht ein DAO doch schon Sinn.

Aber im Grunde genommen sehe ich auch nicht so viele Unterschiede zw. Service + DAO gegenüber den von Dir beschriebenen Repositories, ausser dass mans anders genannt hat.


----------

