Nach wie vor scheint die große Mehrheit Web-Anwendungen zu entwickeln, obwohl man überall von "rich oder smart client" liest - und für unsere Anwendung nur eine solche Variante in Frage kommt.
Das Buch HIA gibt zu Web-Anwendung zahlreiche Beispiele und Vorschläge (Kapitel 8).

Mich interessieren dagegen Vorschläge und Empfehlungen zur Verwendung von Hibernate und der DB in standalone Anwendungen. Diese können z.B mittels eines swing GUIs oder unter Verwendung der eclipse rich client Plattform realisiert werden.

Dass in diesen Fällen die Verwendung einer long session empfohlen wird habe ich im englischsprachigen Forum gelesen (z.B. "Lazy loading with Swing"). Die Frage stellt sich aber nach dem Zugriff auf Hibernate bzw. der DB von der Client Seite aus.

Dabei gibt es zwei grundsätzlich unterschiedliche Ansätze (in beiden Fällen sei angenommen, daß die DB auf einem server läuft):
1. Der Client ruft Hibernate/DB direkt auf, führt also business und persistence code aus (fat client Architektur)
2. Der Client setzt ähnlich wie in einer Web Anwendung requests an den server ab, der den business und persistence code ausführt und Daten an den Client zurückschickt (z.B mittels DTOs, Serialisierung/RMI).

Ich halte den Ansatz 1 für den natürlicheren und einfacheren. Er hat allerdings den Nachteil, daß der business und persistence code auf der Client Seite deployed werden muß. Ob das in Zeiten moderner deployment Werkzeuge wie z.B. Java Webstart wirklich ein Nachteil ist, hängt vom jeweiligen Anwendungsfall ab.

Mich interessiert eure Erfahrung zu diesem Thema bzw. die Motivation, Variante 1 oder 2 (oder vielleicht eine ganz andere) zu wählen.

Sorry, wenn dieser post etwas lang geraten ist, aber ich wollte die Frage so präzise wie möglich stellen.

Helmut

Das kannst Du machen wie Du es fuer richtig haelst, die Probleme werden so ziemlich gleichen sein.

Ich weiß die Antwort kommt einbisserl spät, habe erst jetzt wieder mal bei Hibernate vorbeigeguckt.
Nun ich habe jetzt schon zwei Hibernate Projekte umgesetzt und muss sagen dass die DTO Version sehr elegant ist, aber zudem unheimlich komplex wird! Bei einem grossen Projekt wird die implementierung sehr schwierig, und du codest dich schlicht weg.

Die einfachere Variante ist natürlcih nicht gerade die schönste, da bei einer eventuellen Strukturänderung der DB nicht einfach neu drübergebuilded werden kann, was prinzipiell mit der Variante 1 auch nicht zu 100% Prozent gehen wird.

Wirf eine Münze

Ne, gar nicht spät - danke für die Antwort!

Meine Devise ist: "keep it simple" und deswegen denke ich ist der Preis, mit DTOs (oder anderen Zwischenschichten) zu arbeiten, zu hoch.
Meine Erfahrung ist auch, dass bei standalone Anwendungen eine DB-Schemaänderung meistens auch Änderungen in der view (also auf der Client Seite) mit sich bringt.
Allerdins könnte bei Verwendung von DTOs z.B der business code manchmal ohne deployment auf der Client-Seite gefixt/geändert werden.

Ich sehe bei der Verwendung von DTOs und einer klar definierten Schnittstelle zwischen GUI und der Geschäftslogik noch den Vorteil der Arbeitsteilung. Ich denke die Arbeit lässt sich einfach besser aufteilen, wenn die Schichten klar getrennt sind. Der GUI Entwickler könnte dann zeitweise mit eine Dummy Implementierung der Geschäftslogik arbeiten (Interfaces müssen natürlich definiert sein und eine Factory erzeugt dann die Dummy Implementierung).

Ist das eine theoretische Überlegung oder in einem Projekt so gemacht worden?

Also ich konnte nun mittlerweile in so einige Firmen als Externer reinschnuppern und grad die größeren machen da schon eine klare Trennung. Gerade was das Know-How angeht werden Teams aufgrund ihrer Erfahrungen gebildet. So kann ein Team aus erfahrenen GUI Entwicklern bestehen (vielleicht sogar ein Abteilung) die gerade was Usability angeht und auch den Einsatz der Technologie (Swing, SWT, .Net GUIs) zu verstehen wissen. Wenn dann die Schnittstelle klar definiert ist, dann können die Abteilungen oder Teams getrennt voneinander loslegen und während des Entwicklungsprozesses wird das GUI dann immer wieder gegen die operative Geschäftslogik getestet. Es gibt dann halt ein sogenanntes Interface Projekt wo die Interfaces und die DTOs definiert. Das GUI ruft Methoden der Interfaces auf und verarbeited die gelieferten DTOs. Die GL implementiert die einzelenen Methoden (mit DB Zugriff usw.).

Vielen Dank für die Antwort!
Ja, für große teams kann ich mir vorstellen, daß die Einführung einer Zwischenschicht u.U. Vorteile bringen kann, da hier klare Spielregeln bzw. interfaces und Arbeitsteilung gefordert sind.
Da denke ich halt in anderen Dimensionen: wir sind im team typischerweise zwei bis drei Entwickler, die auf allen Gebieten skilled sind.

Außerdem tendiere ich für die Implementierung in Richtung solcher frameworks wie Naked Objects (www.nakedobjects.org), die eben gerade irigendwelche layers/filter zwischen business domain und User Ebene vermeiden, indem sie das user interface aus dem business model generieren.
(M.E. eine geniale, wenn auch nicht ganz neue Idee; aber leider ist das Naked Objects framework derzeit noch nicht produktionsreif; wahrscheinlich auch nicht für alle Anwendungsfälle erste Wahl).