Est-ce qu'un ORM s'intègre aux applications existantes ou est-ce que je ne comprends pas?

Question

Supposons Hibernate pour l'ORM.

Je ne sais pas comment demander cela. Je veux construire une application qui peut remplacer une partie d'un autre. Par exemple, disons que j'ai une application avec divers modules, appelée la "grande" application. Cette application peut gérer les RH, les finances, les achats, les compétences, etc. Mais peut-être, pour une raison quelconque, je n'aime pas le module de compétences, mais j'aime le reste de l'application. Je veux construire une application qui utilise la même base de données que le reste de la "grosse" application utilise mais utilise mon logiciel comme frontal pour cette pièce.

Je pourrais construire mon application et la faire frapper directement dans la base de données sans ORM. Ma question est de savoir s'il y a un avantage à utiliser un ORM ici. Je pense qu'il y a parce que si la "grande" application disparaît et qu'une autre application est achetée, nous pourrions continuer à utiliser ma version de l'ensemble de compétences parce que j'utilise Hibernate au lieu de frapper les choses directement. J'apprends encore mais je pensais que mon application utilisait des objets que j'ai nommés et que dans le cas que je viens de décrire, je devrais changer mes fichiers de mapping uniquement et/ou mon code très peu.

Voici un autre exemple. J'ai une application héritée et une base de données existante. Il utilise la base de données X. Je décide que je n'aime plus l'ancienne application d'émulation de terminal qui est utilisée pour obtenir les données et que je veux une version graphique. Je peux utiliser Hibernate avec mon application et quand je décide finalement de me débarrasser de la base de données existante et de passer à la dernière version d'Oracle ou de SQL Server, je peux le faire avec un minimum de maux de tête. Ou est-ce que ma base de données va tellement changer que de toute façon cela ne serait pas important (je suggère que plus de renseignements seront stockés lors de la modification d'une nouvelle base de données)?

J'espérais des commentaires, si je ne comprends pas pourquoi Hibernate/ORM pourrait ou non être un avantage.

Merci.

Answer 1

Je ne pense pas que vous ayez un grand avantage frmo hibernate si le schéma de base de données change à quelque chose de complètement différent, vous devrez peut-être changer plus que votre mapping - surtout si plus de structure est ajouté à la base de données , colonne et de telles choses de schéma). Cela dit, si la base de données était structurée de la même façon, mais disons simplement que les noms des colonnes et des tables changent et que quelques tables sont fusionnées ou quelque chose comme ça - vous pouvez vous contenter de changer votre mapping.

Mais je recommande vraiment d'utiliser hbernate pour l'agnosticité de base de données, c'est un chemin assez facile. Et puis tout simplement parce que cela ne vous aide pas vraiment si toute votre base de données est changée, c'est une quantité incroyable d'autres forces, que je choisirais plutôt sur l'accès DB direct la plupart du temps. Enfin, vous pourriez envisager d'utiliser une couche de service telle que le modèle de référentiel qui permet d'abstraire l'accès aux données, de sorte que l'activité de votre appilcation ne devrait pas changer si la base de données change.

Answer 2

Passer d'un SGBD à un autre (de Oracle à SQL Server, par exemple) est une chose que l'utilisation d'un ORM rendrait certainement beaucoup plus facile. En ce qui concerne le passage d'une "grosse application" à une autre "grosse application", je doute que l'utilisation d'un ORM puisse aider. Il est probable que la structure de la base de données et la logique métier soient suffisamment différentes pour que vous puissiez réécrire beaucoup de code de toute façon.

Answer 3

Vous pouvez générer des objets de domaine avec Hibernate Tools, si vous faites cela que ce sera indolore et rapide. Cependant, si vous écrivez tous les objets à la main, vous mourrez. Je pense que c'est une bonne idée de réécrire une partie de l'application et de mieux connaître Hibernate.

Answer 4

Je pense que c'est généralement une mauvaise idée de prendre une décision basée sur les inconnues par rapport aux inconnues. Que vous décidiez d'une stratégie d'accès/persistance de données, quelle voiture acheter, ou quel collège aller , vous devriez mettre le plus de poids sur les choses que vous savez que vous voulez aujourd'hui, plutôt que de se soucier de ce que peut ou peut ne pas arriver demain.

lorsqu'on considère ORM, je ne vous inquiétez pas trop de choses telles que les applications « aller loin » ou DBMSs changer (à moins que ce soit déjà parlé, ou il y a une histoire de cela dans votre entreprise). Je ne dis pas que ce ne sont pas des choses qui ne se produiront jamais, mais plutôt qu'ils devraient passer à côté des considérations généralement plus importantes de maintenabilité, de performance et de productivité des développeurs. Donc, en bref, choisissez un ORM basé sur sa capacité à résoudre les problèmes et à satisfaire les exigences que vous avez aujourd'hui.