Wann kann / sollte man ganzes Schwein mit dem ORM Ansatz gehen?

Question

Es scheint mir, dass ein ORM-Tool Einführung soll Ihre Architektur sauberer machen, aber für Effizienz habe ich finde ich zu umgehen und über einen JDBC Iterieren gelegentlich Ergebnismenge. Dies führt zu einem unkoordinierten Gewirr von Artefakte statt einer saubereren Architektur.

Ist das, weil ich das Werkzeug in einem ungültigen Kontext anwenden, oder ist es tiefer als das?

Wann kann / sollte man ganzes Schwein mit dem ORM Ansatz gehen?

würde Einsicht sehr geschätzt.

---

Ein wenig Hintergrund:

In meinem Umfeld habe ich etwa 50 Client-Computern und 1 einigermaßen leistungsfähige SQL-Server.

Ich habe eine Desktop-Anwendung, in dem alle 50 Kunden jederzeit die Daten zugreifen.

Das Datenmodell des Projektes wird durch eine Reihe von Reorganisationen aus verschiedenen Gründen gegangen einschließlich Klarheit, Effizienz, etc.

Meine Daten Modell der Geschichte

1. JDBC-Aufrufe direkt
2. DAO + POJO ohne Beziehungen zwischen Pojos (im Grunde die JDBC-Verpackung).
3. hinzugefügt Beziehungen zwischen POJOs Lazy Loading-Implementierung, sondern nur versteckt die Inter-DAO ruft
4. Sprang auf die Hibernate fahrenden Zug nachdem er, wie „einfach“ es den Datenzugriff (es machte unter POJO Beziehungen trivial) gemacht, und weil es die Anzahl der Umläufe in die Datenbank verringern könnte, wenn sie mit vielen verbundenen Unternehmen zu arbeiten.
5. Da es sich um eine Desktop-Anwendung war Sessions offen langfristig war ein Alptraum zu halten, so dass es eine ganze Reihe von Fragen endete verursacht
6. trat einen Schritt zurück zu einer partiellen DAO / Hibernate Ansatz, den ich direkt JDBC-Aufrufe hinter dem DAO Vorhang, während zur gleichen Zeit Hibernate.
machen kann

Answer 1

Hibernate macht mehr Sinn, wenn Ihre Anwendung funktioniert auf Objektgraphen , die im RDBMS beibehalten werden. Stattdessen, wenn Ihre Anwendungslogik auf einer 2-D-Matrix von Daten arbeitet, Abrufen von denen über direkte JDBC besser funktioniert. Obwohl Hibernate oben auf JDBC geschrieben wird, hat sie Fähigkeiten, die in JDBC implementieren könnte sein, nicht trivial. Für zB:

1. Sag mal, sieht der Benutzer eine Zeile in der Benutzeroberfläche und ändert einige der Werte, und Sie wollen nur für die Spalten eine Aktualisierungsabfrage feuern, die tatsächlich geändert hat.
2. Um zu vermeiden, in Deadlocks bekommen Sie eine globale Ordnung für SQLs in einer Transaktion zu halten brauchen. dieses Recht JDBC bekommen dürfte nicht leicht sein
3. Leicht optimistische Sperren einrichten. Wenn Sie JDBC verwenden, müssen Sie daran denken, diese Abfrage in jedem Update zu haben.
4. Batch-Updates, faul Materialisierung von Sammlungen usw. auch in JDBC zu implementieren möglicherweise nicht trivial.

(ich sage " könnte nicht-trivial", weil es natürlich getan werden kann - und man könnte ein Super-Hacker sein:)

Hibernate können Sie Ihre eigenen SQL-Abfragen feuern auch, Sie im Falle müssen.

Hope dies hilft Ihnen zu entscheiden.

PS:. Öffnen der Session zu halten auf einem Remote-Desktop-Client und läuft in Schwierigkeiten ist wirklich Problem ist nicht Hibernate - Sie würden in der gleichen Ausgabe führen, wenn Sie die Verbindung zum DB für lange offen zu halten