Wann können/sollten Sie mit dem ORM-Ansatz ganz in Schwung kommen?

Question

Es scheint mir, dass die Einführung eines ORM-Tools Ihre Architektur sauberer machen soll, aber aus Effizienzgründen habe ich festgestellt, dass ich es überspringe und gelegentlich über ein JDBC-Resultset iteriere. Dies führt zu einem unkoordinierten Gewirr von Artefakten anstelle einer saubereren Architektur.

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

Wann können/sollten Sie mit dem ORM-Ansatz ganz und gar gehen?

Jeder Einblick würde sehr geschätzt werden.

---

Ein wenig von Hintergrund:

In meiner Umgebung, die ich über 50 Client-Computer und 1 einigermaßen leistungsfähigen SQL-Server habe.

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

Das Projektdatenmodell aus verschiedenen Gründen, einschließlich Klarheit, Effizienz, usw. durch eine Reihe von Reorganisationen gegangen

My Data Model Geschichte

1. JDBC-Aufrufe direkt
2. DAO + POJO ohne Beziehungen zwischen Pojos (im Grunde die JDBC Wrapping).
3. Added Beziehungen zwischen POJOs Umsetzung Lazy Loading-, sondern nur versteckt die Inter-DAO ruft
4. auf die Hibernate-Zug aufgesprungen, nachdem er, wie „einfach“ es den Datenzugriff gemacht (es unter POJO Beziehungen trivial gemacht), und weil es verringern könnte die Anzahl der Rundreisen in die Datenbank bei der Arbeit mit vielen verwandten Entitäten.
5. Da es eine Desktop-Anwendung war, Sessions langfristig geöffnet zu lassen, war ein Albtraum, so dass es eine ganze Reihe von Problemen verursachte
6. Zurück zu einem partiellen DAO/Hibernate-Ansatz, der mir direkte JDBC-Aufrufe hinter dem DAO ermöglicht Vorhang und gleichzeitig Hibernate.

Answer 1

Hibernate macht mehr Sinn, wenn Ihre Anwendung funktioniert auf Objektgraphen, die in der RDBMS beibehalten werden. Wenn Ihre Anwendungslogik stattdessen auf einer 2-D-Matrix von Daten arbeitet, funktioniert das Abrufen von diesen über direkte JDBC besser. Obwohl Hibernate auf JDBC geschrieben wird, verfügt es über Funktionen, die in JDBC nicht einfach zu implementieren sind. ZB:

1. Angenommen, der Benutzer sieht eine Zeile in der Benutzeroberfläche und ändert einige der Werte und Sie möchten eine Update-Abfrage nur für die Spalten auslösen, die sich tatsächlich geändert haben.
2. Um zu vermeiden, in Deadlocks bekommen Sie eine globale Ordnung für SQLs in einer Transaktion zu halten brauchen. Die richtige Einstellung JDBC ist möglicherweise nicht einfach
3. Einfaches Einrichten der optimistischen Sperre. Wenn Sie JDBC verwenden, müssen Sie daran denken, dies in jeder Aktualisierungsabfrage zu haben.
4. Batch-Updates, faul Materialisierung von Sammlungen usw. könnten auch nicht-trivial werden in JDBC zu implementieren.

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

Hibernate Sie auch Abfragen Feuer Ihre eigene SQL lässt, falls du musst.

Hoffe das hilft Ihnen bei der Entscheidung.

PS: Es ist wirklich nicht das Problem von Hibernate, die Sitzung auf einem Remotedesktopclient geöffnet zu halten und Probleme zu bekommen - das gleiche Problem würde auftreten, wenn Sie die Verbindung zur Datenbank lange geöffnet lassen.