Quand pouvez-vous/devez-vous vous lancer à fond dans l’approche ORM ?

Question

Il me semble que l'introduction d'un outil ORM est censée rendre votre architecture plus propre, mais pour des raisons d'efficacité, je me suis retrouvé à le contourner et à parcourir un jeu de résultats JDBC à l'occasion.Cela conduit à un enchevêtrement non coordonné d’artefacts au lieu d’une architecture plus propre.

Est-ce parce que j'applique l'outil dans un contexte non valide, ou est-ce plus profond que cela ?

Quand pouvez-vous/devez-vous vous lancer à fond dans l’approche ORM ?

Toute idée serait grandement apprécié.

---

Un peu de contexte :

Dans mon environnement, j'ai environ 50 ordinateurs clients et 1 serveur SQL raisonnablement puissant.

J'ai une application de bureau dans laquelle les 50 clients accèdent aux données à tout moment.

Le modèle de données du projet a subi un certain nombre de réorganisations pour diverses raisons, notamment la clarté, l'efficacité, etc.

Historique de mon modèle de données

1. JDBC appelle directement
2. DAO + POJO sans relations entre Pojos (enveloppant essentiellement le JDBC).
3. Ajout de relations entre les POJO implémentant le Lazy Loading, mais masquant simplement les appels inter-DAO
4. J'ai sauté dans le train Hibernate après avoir vu à quel point il rendait l'accès aux données "simple" (cela rendait les relations inter POJO triviales) et parce qu'il pouvait réduire le nombre d'allers-retours vers la base de données lorsque l'on travaillait avec de nombreuses entités associées.
5. Puisqu'il s'agissait d'une application de bureau, garder les sessions ouvertes à long terme était un cauchemar, cela a donc fini par causer de nombreux problèmes.
6. Je suis revenu à une approche partielle DAO/Hibernate qui me permet de passer des appels JDBC directs derrière le rideau DAO tout en utilisant Hibernate.

Answer 1

Hibernate a plus de sens lorsque votre application fonctionne sur graphiques d'objets, qui sont conservés dans le SGBDR.Au lieu de cela, si la logique de votre application fonctionne sur une matrice de données 2D, la récupération de celles-ci via JDBC direct fonctionne mieux.Bien qu'Hibernate soit écrit sur JDBC, il possède des fonctionnalités qui pourraient ne pas être triviales à implémenter dans JDBC.Par exemple :

1. Supposons que l'utilisateur affiche une ligne dans l'interface utilisateur et modifie certaines valeurs et que vous souhaitiez lancer une requête de mise à jour uniquement pour les colonnes qui ont effectivement changé.
2. Pour éviter de vous retrouver dans des impasses, vous devez maintenir un ordre global pour les SQL dans une transaction.Réussir les choses avec JDBC n'est peut-être pas facile
3. Configuration facile du verrouillage optimiste.Lorsque vous utilisez JDBC, vous devez vous rappeler de l'avoir dans chaque requête de mise à jour.
4. Les mises à jour par lots, la matérialisation paresseuse des collections, etc. peuvent également être non triviales à implémenter dans JDBC.

(Je dis "pourrait être non trivial", car cela peut bien sûr être fait - et vous pourriez être un super hacker :)

Hibernate vous permet également de lancer vos propres requêtes SQL, au cas où vous en auriez besoin.

J'espère que cela vous aidera à décider.

PS :Garder la session ouverte sur un client de bureau distant et rencontrer des problèmes n'est vraiment pas le problème d'Hibernate - vous rencontreriez le même problème si vous gardez la connexion à la base de données ouverte pendant longtemps.