Y a-t-il de bonnes raisons de ne pas utiliser un ORM? [fermé]

Pendant mon apprentissage, j'ai utilisé NHibernate pour certains petits projets que j'ai principalement codés et conçus par moi-même. Maintenant, avant de démarrer un projet plus important, la discussion a porté sur la manière de concevoir l'accès aux données et sur l'utilisation ou non d'une couche ORM. Comme je suis encore en apprentissage et que je me considère toujours comme un débutant en programmation d'entreprise, je n'ai pas vraiment essayé de pousser à mon avis, qui est que l'utilisation d'un mappeur relationnel objet dans la base de données peut faciliter beaucoup le développement. Les autres codeurs de l'équipe de développement sont beaucoup plus expérimentés que moi, donc je pense que je vais faire ce qu'ils disent. :-)

Cependant, je ne comprends pas complètement deux des principales raisons de ne pas utiliser NHibernate ou un projet similaire:

1. On peut simplement créer ses propres objets d'accès aux données avec des requêtes SQL et copier ces requêtes hors de Microsoft SQL Server Management Studio.
2. Le débogage d'un ORM peut être difficile.

Donc, bien sûr, je pourrais simplement créer ma couche d'accès aux données avec beaucoup de SELECTs, etc., mais ici je manque l'avantage des jointures automatiques, des classes proxy à chargement paresseux et un effort de maintenance moindre si une table obtient une nouvelle colonne ou une colonne obtient renommé. (Mise à jour de nombreuses SELECT, INSERTet les UPDATErequêtes contre la mise à jour de la configuration de la cartographie et la refactorisation éventuellement les classes d'affaires et DTO.)

De plus, en utilisant NHibernate, vous pouvez rencontrer des problèmes imprévus si vous ne connaissez pas très bien le framework. Cela peut être, par exemple, de faire confiance au Table.hbm.xml où vous définissez la longueur d'une chaîne pour qu'elle soit automatiquement validée. Cependant, je peux également imaginer des bogues similaires dans une couche d'accès aux données basée sur une requête SqlConnection «simple».

Enfin, ces arguments mentionnés ci-dessus sont-ils vraiment une bonne raison de ne pas utiliser un ORM pour une application d'entreprise basée sur une base de données non triviale? Y a-t-il probablement d'autres arguments qu'ils / j'aurais pu manquer?

(Je devrais probablement ajouter que je pense que c'est comme la première "grande" application basée sur .NET / C # qui nécessitera un travail d'équipe. Les bonnes pratiques, qui sont considérées comme assez normales sur Stack Overflow, telles que les tests unitaires ou l'intégration continue, ne sont pas -existant ici jusqu'à présent.)

Il y a eu une explosion de croissance avec les ORM ces dernières années et vos collègues plus expérimentés pensent peut-être encore dans la mentalité «chaque appel de base de données doit être effectué par une procédure stockée».

Pourquoi un ORM rendrait-il les choses plus difficiles à déboguer? Vous obtiendrez le même résultat, qu'il provienne d'un processus stocké ou de l'ORM.

Je suppose que le seul véritable inconvénient auquel je puisse penser avec un ORM est que le modèle de sécurité est un peu moins flexible.

EDIT: Je viens de relire votre question et il semble qu'ils copient et collent les requêtes dans SQL en ligne. Cela rend le modèle de sécurité identique à un ORM, il n'y aurait donc absolument aucun avantage sur cette approche par rapport à un ORM. S'ils utilisent des requêtes non paramétrées, ce serait en fait un risque pour la sécurité.

La réponse courte est oui, il y a de très bonnes raisons. En fait, il y a des cas où vous ne pouvez tout simplement pas utiliser un ORM.

Par exemple, je travaille pour une grande institution financière et nous devons suivre de nombreuses directives de sécurité. Pour respecter les règles et réglementations qui nous sont imposées, la seule façon de réussir les audits est de conserver l'accès aux données dans le cadre de procédures stockées. Maintenant, certains peuvent dire que c'est tout simplement stupide, mais honnêtement ce n'est pas le cas. L'utilisation d'un outil ORM signifie que l'outil / développeur peut insérer, sélectionner, mettre à jour ou supprimer ce qu'il ou elle veut. Les procédures stockées offrent beaucoup plus de sécurité, en particulier dans les environnements lorsqu'ils traitent des données client. Je pense que c'est la principale raison à considérer. Sécurité.

Le sweet spot des ORM

Les ORM sont utiles pour automatiser plus de 95% des requêtes lorsqu'elles sont applicables. Leur force particulière réside dans le fait que vous disposez d'une application avec une architecture de modèle objet solide et une base de données qui joue bien avec ce modèle objet. Si vous faites une nouvelle construction et que vous avez de solides compétences en modélisation dans votre équipe, vous obtiendrez probablement de bons résultats avec un ORM.

Vous pouvez très bien avoir une poignée de requêtes qu'il vaut mieux faire à la main. Dans ce cas, n'ayez pas peur d'écrire quelques procédures stockées pour gérer cela. Même si vous avez l'intention de porter votre application sur plusieurs plates-formes de SGBD, le code dépendant de la base de données sera minoritaire. Sachant que vous devrez tester votre application sur n'importe quelle plate-forme sur laquelle vous avez l'intention de la prendre en charge, un peu d'effort de portage supplémentaire pour certaines procédures stockées ne fera pas beaucoup de différence sur votre TCO. Pour une première approximation, 98% portable est tout aussi bon que 100% portable, et bien mieux que des solutions alambiquées ou peu performantes pour contourner les limites d'un ORM.

J'ai vu la première approche bien fonctionner sur un très grand projet J2EE (des centaines d'années-employés).

Où un ORM peut ne pas être le meilleur ajustement

Dans d'autres cas, il peut y avoir des approches qui conviennent mieux à l'application qu'un ORM. Les modèles d'architecture d'applications d'entreprise de Fowler ont une section sur les modèles d'accès aux données qui fait un assez bon travail de catalogage de diverses approches à ce sujet. Voici quelques exemples que j'ai vus de situations dans lesquelles un ORM peut ne pas être applicable:

• Sur une application avec une base de code héritée substantielle de procédures stockées, vous pouvez utiliser une couche d'accès aux données orientée fonctionnellement (à ne pas confondre avec les langages fonctionnels) pour envelopper les sprocs en place. Cela réutilise la couche d'accès aux données et la conception de base de données existantes (et donc testées et déboguées), ce qui représente souvent un effort de développement et de test assez important, et évite d'avoir à migrer les données vers un nouveau modèle de base de données. C'est souvent un bon moyen d'encapsuler les couches Java autour de bases de code PL / SQL héritées, ou de recibler les applications clientes riches VB, Powerbuilder ou Delphi avec des interfaces Web.

• Une variante est l'endroit où vous héritez d'un modèle de données qui n'est pas nécessairement bien adapté au mappage OR. Si (par exemple) vous écrivez une interface qui remplit ou extrait des données d'une interface étrangère, vous feriez peut-être mieux de travailler directement avec la base de données.

• Applications financières ou autres types de systèmes où l'intégrité des données intersystème est importante, en particulier si vous utilisez des transactions distribuées complexes avec validation en deux phases. Vous devrez peut-être microgérer vos transactions mieux qu'un ORM ne peut le supporter.

• Applications hautes performances où vous souhaitez vraiment régler votre accès à la base de données. Dans ce cas, il peut être préférable de travailler à un niveau inférieur.

• Les situations dans lesquelles vous utilisez un mécanisme d'accès aux données en place comme ADO.Net qui est `` assez bon '' et qui joue bien avec la plate-forme est d'un plus grand avantage que l'ORM n'apporte.

• Parfois, les données ne sont que des données - il peut arriver (par exemple) que votre application travaille avec des «transactions» plutôt que des «objets» et qu'il s'agisse d'une vue sensée du domaine. Un exemple de ceci pourrait être un package financier dans lequel vous avez des transactions avec des champs d'analyse configurables. Bien que l'application elle-même puisse être construite sur une plate-forme OO, elle n'est pas liée à un modèle de domaine métier unique et peut ne pas connaître beaucoup plus que les codes GL, les comptes, les types de documents et une demi-douzaine de champs d'analyse. Dans ce cas, l'application n'a pas connaissance d'un modèle de domaine métier en tant que tel et un modèle objet (au-delà de la structure du grand livre elle-même) n'est pas pertinent pour l'application.

Tout d'abord, l'utilisation d'un ORM ne rendra pas votre code plus facile à tester, ni ne fournira nécessairement aucun avantage dans un scénario d'intégration continue.

D'après mon expérience, bien que l'utilisation d'un ORM puisse augmenter la vitesse de développement, les plus gros problèmes que vous devez résoudre sont:

1. Tester votre code
2. Maintenir votre code

Les solutions à ces problèmes sont:

1. Rendez votre code testable (en utilisant les principes SOLID )
2. Rédiger des tests automatisés pour autant de code que possible
3. Exécutez les tests automatisés aussi souvent que possible

Pour en venir à votre question, les deux objections que vous énumérez semblent plus être de l'ignorance qu'autre chose.

Ne pas pouvoir écrire des requêtes SELECT à la main (ce qui, je suppose, est la raison pour laquelle le copier-coller est nécessaire) semble indiquer qu'il y a un besoin urgent de formation SQL.

Il y a deux raisons pour lesquelles je n'utiliserais pas d'ORM:

1. C'est strictement interdit par la politique de l'entreprise (auquel cas j'irais travailler ailleurs)
2. Le projet est extrêmement gourmand en données et l'utilisation de solutions spécifiques au fournisseur (comme BulkInsert) est plus logique.

Les rebuffades habituelles sur les ORM (NHibernate en particulier) sont:

1. La vitesse

   Il n'y a aucune raison pour laquelle l'utilisation d'un ORM serait plus lente que l'accès aux données codé à la main. En fait, en raison de la mise en cache et des optimisations intégrées, cela peut être plus rapide. Un bon ORM produira un ensemble répétable de requêtes pour lesquelles vous pourrez optimiser votre schéma. Un bon ORM permettra également une récupération efficace des données associées à l'aide de diverses stratégies de récupération.

2. Complexité

   En ce qui concerne la complexité, utiliser un ORM signifie moins de code, ce qui signifie généralement moins de complexité. De nombreuses personnes utilisant l'accès aux données manuscrites (ou générées par code) se retrouvent à écrire leur propre cadre sur des bibliothèques d'accès aux données de «bas niveau» (comme l'écriture de méthodes d'aide pour ADO.Net). Cela équivaut à plus de complexité et, pire encore, ils sont rarement bien documentés ou bien testés.
   Si vous regardez spécifiquement NHibernate, des outils comme Fluent NHibernate et Linq To NHibernate adoucissent également la courbe d'apprentissage.

Ce qui m'interpelle dans tout le débat sur l'ORM, c'est que les mêmes personnes qui prétendent que l'utilisation d'un ORM sera trop difficile / lent / peu importe ce sont les mêmes personnes qui sont plus qu'heureuses d'utiliser Linq To Sql ou des ensembles de données typés. Alors que Linq To Sql est un grand pas dans la bonne direction, il reste encore des années-lumière derrière certains des ORM open source. Cependant, les cadres pour les ensembles de données typés et pour Linq To Sql sont toujours extrêmement complexes, et les utiliser pour aller trop loin du (Table = Class) + (CRUD de base) est stupidement difficile.

Mon conseil est que si, à la fin de la journée, vous ne pouvez pas obtenir d'ORM, assurez-vous que votre accès aux données est séparé du reste du code et que vous suivez les conseils de codage du Gang Of Four pour une interface. Procurez-vous également un cadre d'injection de dépendance pour effectuer le câblage.

(Comment est-ce pour une diatribe?)

Il existe un large éventail de problèmes courants pour lesquels les outils ORM comme Hibernate sont un don du ciel, et quelques-uns où c'est un obstacle. Je ne connais pas suffisamment votre projet pour savoir de quoi il s'agit.

L'un des points forts d'Hibernate est que vous ne pouvez dire les choses que 3 fois: chaque propriété est mentionnée dans la classe, le fichier .hbm.xml et la base de données. Avec les requêtes SQL, vos propriétés se trouvent dans la classe, la base de données, les instructions select, les instructions insert, les instructions update, les instructions delete et tout le code de marshalling et de démarshalling supportant vos requêtes SQL! Cela peut devenir désordonné rapidement. D'autre part, vous savez comment cela fonctionne. Vous pouvez le déboguer. Tout est là dans votre propre couche de persistance, pas enterré dans les entrailles d'un outil tiers.

Hibernate pourrait être un enfant d'affiche pour la loi des abstractions baveuses de Spolsky. Sortez un peu des sentiers battus et vous devez connaître le fonctionnement interne approfondi de l'outil. Cela peut être très ennuyeux quand vous savez que vous pourriez avoir corrigé le SQL en quelques minutes, mais au lieu de cela, vous passez des heures à essayer de cajoler votre outil dang en générant du SQL raisonnable. Le débogage est parfois un cauchemar, mais il est difficile de convaincre des personnes qui n'y sont pas allées.

EDIT: Vous voudrez peut-être regarder dans iBatis.NET s'ils ne vont pas être retournés à propos de NHibernate et qu'ils veulent contrôler leurs requêtes SQL.

EDIT 2: Voici le gros drapeau rouge, cependant: "Les bonnes pratiques, qui sont considérées comme assez normales sur Stack Overflow, telles que les tests unitaires ou l'intégration continue, n'existent pas ici jusqu'à présent." Alors, ces développeurs "expérimentés", quelle expérience ont-ils dans le développement? Leur sécurité d'emploi? On dirait que vous faites peut-être partie de personnes qui ne sont pas particulièrement intéressées par le domaine, alors ne les laissez pas tuer votre intérêt. Vous devez être l'équilibre. Combattez.

J'ai travaillé sur un projet où ne pas utiliser d'ORM était très réussi. C'était un projet qui

1. Doit être à l'échelle horizontale depuis le début
2. Doit être développé rapidement
3. Avait un modèle de domaine relativement simple

Le temps qu'il aurait fallu pour que NHibernate fonctionne dans une structure partitionnée horizontalement aurait été beaucoup plus long que le temps qu'il a fallu pour développer un datamapper super simple qui était conscient de notre schéma de partitionnement ...

Donc, dans 90% des projets que j'ai travaillé sur un ORM a été une aide précieuse. Mais il y a des circonstances très spécifiques où je peux voir que ne pas utiliser d'ORM comme étant le meilleur.

Permettez-moi d'abord de dire que les ORM peuvent vous faciliter la vie de développement s'ils sont correctement intégrés, mais il y a une poignée de problèmes où l'ORM peut réellement vous empêcher d'atteindre vos exigences et objectifs déclarés.

J'ai constaté que lors de la conception de systèmes qui ont des exigences de performance élevées, je suis souvent mis au défi de trouver des moyens de rendre le système plus performant. Plusieurs fois, je me retrouve avec une solution qui a un profil de performances d'écriture élevé (ce qui signifie que nous écrivons beaucoup plus de données que nous lisons des données). Dans ces cas, je souhaite profiter des facilités que la plateforme de base de données m'offre pour atteindre nos objectifs de performance (c'est OLTP, pas OLAP). Donc, si j'utilise SQL Server et que je sais que j'ai beaucoup de données à écrire, pourquoi n'utiliserais-je pas une insertion en bloc ... eh bien, comme vous l'avez peut-être déjà découvert, la plupart des ORMS (je ne sais pas si même un seul n'a pas la possibilité de profiter des avantages spécifiques de la plate-forme comme l'insert en vrac.

Vous devez savoir que vous pouvez mélanger les techniques ORM et non ORM. Je viens de découvrir qu'il existe une poignée de cas extrêmes où les ORM ne peuvent pas prendre en charge vos besoins et que vous devez les contourner pour ces cas.

Lorsque vous devez mettre à jour 50000000 enregistrements. Définissez un drapeau ou autre.

Essayez de faire cela en utilisant un ORM sans appeler une procédure stockée ou des commandes SQL natives.

Mise à jour 1: essayez également de récupérer un enregistrement avec seulement quelques-uns de ses champs. (Lorsque vous avez une table très "large"). Ou un résultat scalaire. Les ORM sont nuls aussi.

MISE À JOUR 2 : Il semble qu'EF 5.0 bêta promet des mises à jour par lots, mais c'est une nouvelle très chaude (2012, janvier)

Pour une application d'entreprise basée sur une base de données non triviale, il n'y a vraiment aucune justification à ne pas utiliser un ORM.

Caractéristiques de côté:

• En n'utilisant pas d'ORM, vous résolvez un problème qui a déjà été résolu à plusieurs reprises par de grandes communautés ou des entreprises disposant de ressources importantes.
• En utilisant un ORM, l'élément central de votre couche d'accès aux données bénéficie des efforts de débogage de cette communauté ou entreprise.

Pour mettre l'argument en perspective, considérez les avantages de l'utilisation d'ADO.NET par rapport à l'écriture du code pour analyser vous-même le flux de données tabulaire.

J'ai vu l'ignorance sur la façon d'utiliser un ORM justifier le dédain d'un développeur pour les ORM Par exemple: chargement impatient (quelque chose que j'ai remarqué que vous n'avez pas mentionné). Imaginez que vous vouliez récupérer un client et toutes ses commandes, et pour ces tous les éléments de détail de la commande. Si vous comptez uniquement sur le chargement paresseux, vous abandonnerez votre expérience ORM avec l'opinion: "Les ORM sont lents". Si vous apprenez à utiliser le chargement hâtif, vous ferez en 2 minutes avec 5 lignes de code, ce que vos collègues mettront en une demi-journée à mettre en œuvre: une requête à la base de données et lier les résultats à une hiérarchie d'objets. Un autre exemple serait la douleur d'écrire manuellement des requêtes SQL pour implémenter la pagination.

L'exception possible à l'utilisation d'un ORM serait si cette application était un framework ORM conçu pour appliquer des abstractions de logique métier spécialisées et conçu pour être réutilisé sur plusieurs projets. Même si tel était le cas, vous obtiendrez une adoption plus rapide en améliorant un ORM existant avec ces abstractions.

Ne laissez pas l'expérience des membres de votre équipe senior vous entraîner dans la direction opposée de l'évolution de l'informatique. Je développe professionnellement depuis 23 ans, et l'une des constantes est le mépris du nouveau par la vieille école. Les ORM sont en SQL comme le langage C l'était à l'assemblage, et vous pouvez parier que les équivalents de C ++ et C # sont en route. Une ligne de code de la nouvelle école équivaut à 20 lignes de la vieille école.

Je pense que peut-être que lorsque vous travaillez sur des systèmes plus gros, vous pouvez utiliser un outil générateur de code comme CodeSmith au lieu d'un ORM ... J'ai récemment trouvé ceci: Cooperator Framework qui génère des procédures stockées SQL Server et génère également vos entités commerciales, mappeurs, passerelles, lazyload et tout ce truc en C # ... regardez-le ... il a été écrit par une équipe ici en Argentine ...

Je pense que c'est entre le codage de toute la couche d'accès aux données et l'utilisation d'un ORM ...

Personnellement, je me suis (jusqu'à récemment) opposé à l'utilisation d'un ORM, et utilisé pour m'en sortir avec l'écriture d'une couche d'accès aux données encapsulant toutes les commandes SQL. La principale objection aux ORM était que je ne faisais pas confiance à l'implémentation ORM pour écrire exactement le bon SQL. Et, à en juger par les ORM que je voyais (principalement des bibliothèques PHP), je pense que j'avais tout à fait raison.

Maintenant, la majeure partie de mon développement Web utilise Django, et j'ai trouvé l'ORM inclus très pratique, et comme le modèle de données est d'abord exprimé dans leurs termes, et seulement plus tard en SQL, il fonctionne parfaitement pour mes besoins. Je suis sûr qu'il ne serait pas trop difficile de le dépasser et qu'il faudrait le compléter avec du SQL écrit à la main; mais pour CRUD, l'accès est plus que suffisant.

Je ne sais pas pour NHibernate; mais je suppose que c'est aussi "assez bon" pour la plupart de ce dont vous avez besoin. Mais si les autres codeurs ne lui font pas confiance; ce sera le principal suspect sur chaque bogue lié aux données, ce qui rendra la vérification plus fastidieuse.

Vous pouvez essayer de l'introduire progressivement dans votre lieu de travail, en vous concentrant d'abord sur les petites applications «évidentes», comme un simple accès aux données. Après un certain temps, il pourrait être utilisé sur des prototypes, et il pourrait ne pas être remplacé ...

S'il s'agit d'une base de données OLAP (par exemple, des données statiques en lecture seule utilisées pour les rapports / analyses, etc.), la mise en œuvre d'un cadre ORM n'est pas appropriée. Au lieu de cela, il serait préférable d'utiliser la fonctionnalité d'accès aux données native de la base de données, comme les procédures stockées. Les ORM sont mieux adaptés aux systèmes transactionnels (OLTP).

Je pense qu'il y a de nombreuses bonnes raisons de ne pas utiliser d'ORM. Avant tout, je suis un développeur .NET et j'aime m'en tenir à ce que le merveilleux framework .NET m'a déjà fourni. Il fait tout ce dont j'ai besoin. En faisant cela, vous restez avec une approche plus standard, et il y a donc de bien meilleures chances que tout autre développeur travaillant sur le même projet plus tard, puisse récupérer ce qui est là et fonctionner avec lui. Les capacités d'accès aux données déjà fournies par Microsoft sont assez larges, il n'y a aucune raison de les supprimer.

Je suis développeur professionnel depuis 10 ans, je dirige plusieurs projets de plus d'un million de dollars très réussis, et je n'ai jamais écrit une seule fois une application qui devait pouvoir basculer vers une base de données. Pourquoi voudriez-vous qu'un client fasse cela? Planifiez soigneusement, choisissez la bonne base de données pour ce dont vous avez besoin et respectez-la. Personnellement, SQL Server a été capable de faire tout ce que j'avais besoin de faire. C'est facile et ça marche très bien. Il existe même une version gratuite qui prend en charge jusqu'à 10 Go de données. Oh, et cela fonctionne très bien avec .NET.

J'ai récemment dû commencer à travailler sur plusieurs projets qui utilisent un ORM comme datalayer. Je pense que c'est mauvais, et quelque chose de plus que j'ai dû apprendre à utiliser sans aucune raison. Dans la circonstance incroyablement rare où le client avait besoin de changer de base de données, j'aurais facilement pu retravailler l'ensemble du datalayer en moins de temps que je n'ai passé à tromper les fournisseurs ORM.

Honnêtement, je pense qu'il y a une vraie utilisation pour un ORM: si vous créez une application comme SAP qui a vraiment besoin de la capacité de fonctionner sur plusieurs bases de données. Sinon, en tant que fournisseur de solutions, je dis à mes clients que cette application est conçue pour fonctionner sur cette base de données et que c'est ainsi. Encore une fois, après 10 ans et un nombre incalculable d'applications, cela n'a jamais posé de problème.

Sinon, je pense que les ORM sont destinés aux développeurs qui ne comprennent pas moins, c'est plus, et je pense que plus les outils tiers qu'ils utilisent dans leur application seront bons, mieux leur application sera. Je vais laisser des choses comme ça aux super geeks endurcis pendant que je crée des logiciels beaucoup plus géniaux en attendant que n'importe quel développeur puisse prendre et être immédiatement productif.

Les performances d'exécution sont le seul inconvénient réel auquel je puisse penser, mais je pense que c'est plus qu'un compromis équitable pour le temps que l'ORM vous fait gagner en développement / test / etc. Et dans la plupart des cas, vous devriez être en mesure de localiser les goulots d'étranglement des données et de modifier les structures de vos objets pour être plus efficace.

Je n'ai jamais utilisé Hibernate auparavant, mais une chose que j'ai remarquée avec quelques solutions ORM «prêtes à l'emploi» est un manque de flexibilité. Je suis sûr que cela dépend de ce que vous choisissez et de ce que vous devez en faire.

Il y a deux aspects des ORM qui sont inquiétants. Premièrement, il s'agit de code écrit par quelqu'un d'autre, parfois en source fermée, parfois en open source mais de grande portée. Deuxièmement, ils copient les données.

Le premier problème provoque deux problèmes. Vous vous fiez au code des étrangers. Nous faisons tous cela, mais le choix de le faire ne doit pas être pris à la légère. Et si cela ne fait pas ce dont vous avez besoin? Quand découvrirez-vous cela? Vous vivez dans la boîte que votre ORM dessine pour vous.

Le deuxième problème est celui de la validation en deux phases. La base de données relationnelle est copiée dans un modèle objet. Vous modifiez le modèle d'objet et il est censé mettre à jour la base de données. Il s'agit d'un commit en deux phases et non de la chose la plus simple à déboguer.

Je suggère cette lecture pour une liste des inconvénients des ORM.

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Pour moi, j'ai trouvé les ORM très utiles pour la plupart des applications que j'ai écrites!

/ Asger

L'expérience que j'ai eue avec Hibernate est que sa sémantique est subtile, et quand il y a des problèmes, il est un peu difficile de comprendre ce qui ne va pas sous le capot. J'ai entendu d'un ami dire que souvent on commence par Criteria, puis on a besoin d'un peu plus de flexibilité et de HQL, et plus tard on remarque qu'après tout, du SQL brut est nécessaire (par exemple, Hibernate n'a pas l'union AFAIK).

De plus, avec ORM, les gens ont facilement tendance à surutiliser les mappages / modèles existants, ce qui conduit à ce qu'il y ait un objet avec de nombreux attributs qui ne sont pas initiés. Ainsi, après la requête, la transaction interne Hibernate effectue une récupération de données supplémentaire, ce qui entraîne un ralentissement potentiel. Malheureusement, l'objet de modèle de mise en veille prolongée est parfois divulgué dans la couche d'architecture de vue, puis nous voyons LazyInitializationExceptions.

Pour utiliser ORM, il faut vraiment le comprendre. Malheureusement, on a facilement l'impression que c'est facile alors que ce n'est pas le cas.

Pour ne pas être une réponse en soi, je souhaite reformuler une citation que j'ai entendue récemment. "Un bon ORM est comme un Yeti, tout le monde en parle mais personne ne le voit."

Chaque fois que je mets la main sur un ORM, je me trouve généralement aux prises avec les problèmes / limitations de cet ORM. À la fin, oui, il fait ce que je veux et il a été écrit quelque part dans cette documentation moche, mais je me retrouve à perdre une heure de plus que je n'aurai jamais. Quiconque utilisait nhibernate, puis couramment nhibernate sur postgresql comprendrait ce que j'ai vécu. Le sentiment constant de "ce code n'est pas sous mon contrôle" est vraiment nul.

Je ne pointe pas du doigt ou ne dis pas qu'ils sont mauvais, mais j'ai commencé à penser à ce que je donne juste pour automatiser CRUD en une seule expression. De nos jours, je pense que je devrais utiliser moins d'ORM, peut-être créer ou trouver une solution qui permette au minimum les opérations de base de données. Mais c'est juste moi. Je crois que certaines choses ne vont pas dans cette arène ORM mais je ne suis pas assez habile pour l'exprimer quoi que ce soit.

Je pense qu'utiliser un ORM est toujours une bonne idée. Surtout compte tenu de la situation que vous donnez. Il semble que par votre message, vous êtes le plus expérimenté en ce qui concerne les stratégies d'accès à la base de données, et je parlerais de l'utilisation d'un ORM.

Il n'y a pas d'argument pour le n ° 1 car le fait de copier-coller des requêtes et de coder en dur dans du texte ne donne aucune flexibilité, et pour le n ° 2, la plupart des orm encapsuleront l'exception d'origine, permettront de suivre les requêtes générées, etc., donc le débogage n'est pas sorcier non plus.

En ce qui concerne la validation, l'utilisation d'un ORM permettra également généralement de développer des stratégies de validation beaucoup plus facilement, en plus de toute validation intégrée.

La rédaction de votre propre cadre peut être laborieuse et souvent des choses sont manquées.

EDIT: Je voulais faire un autre point. Si votre entreprise adopte une stratégie ORM, cela augmente encore sa valeur, car vous développerez des directives et des pratiques d'utilisation et de mise en œuvre et chacun améliorera encore sa connaissance du cadre choisi, atténuant l'un des problèmes que vous avez soulevés. En outre, vous apprendrez ce qui fonctionne et ce qui ne fonctionne pas lorsque des situations surviennent et, à la fin, vous économiserez beaucoup de temps et d'efforts.

Chaque ORM, même un «bon», est accompagné d'un certain nombre d'hypothèses liées aux mécanismes sous-jacents que le logiciel utilise pour transmettre des données dans les deux sens entre votre couche d'application et votre magasin de données.

J'ai constaté que pour une application modérément sophistiquée, travailler autour de ces hypothèses me prend généralement plus de temps que d'écrire simplement une solution plus simple telle que: interroger les données et instancier manuellement de nouvelles entités.

En particulier, vous risquez de rencontrer des problèmes dès que vous utilisez des clés à plusieurs colonnes ou d'autres relations modérément complexes qui sortent juste du cadre des exemples pratiques que votre ORM vous a fournis lorsque vous avez téléchargé le code.

Je concède que pour certains types d'applications, en particulier celles qui ont un très grand nombre de tables de base de données, ou de tables de base de données générées dynamiquement, que le processus d'auto-magie d'un ORM peut être utile.

Sinon, au diable les ORM. Je les considère maintenant comme une mode.