Y a-t-il de bonnes raisons de ne pas utiliser un ORM?
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 commencer un projet plus important, la discussion a commencé sur la façon de concevoir l'accès aux données et d'utiliser ou non une couche ORM. Comme je suis encore dans mon 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, c'est-à-dire que l'utilisation d'un mappeur relationnel d'objet dans la base de données peut faciliter considérablement 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 ferai juste ce qu'ils disent. :-)
Cependant, je ne comprends pas complètement deux des principales raisons de ne pas utiliser NHibernate ou un projet similaire:
- On peut simplement créer ses propres objets d'accès aux données avec des requêtes SQL et copier ces requêtes à partir de Microsoft SQL Server Management Studio.
- 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 ou une colonne est renommée. (Mise à jour de nombreuses requêtes SELECT, INSERT et UPDATE par rapport à la mise à jour de la configuration de mappage et éventuellement à la refactorisation des classes métier et des DTO.)
En outre, en utilisant NHibernate, vous pouvez rencontrer des problèmes imprévus si vous ne connaissez pas très bien le cadre. Cela pourrait être, par exemple, 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 "simple" SqlConnection.
Enfin, les 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'ai pu manquer?
(Je devrais probablement ajouter que je pense que cela ressemble à 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 au cours des dernières années et vos collègues plus expérimentés peuvent encore penser dans la mentalité "chaque appel de base de données doit passer 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 proc stocké ou de l'ORM.
Je suppose que le seul véritable inconvénient auquel je peux 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 vraiment de 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 maintenir l'accès aux données dans les 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 tout ce qu'il veut. Les procédures stockées offrent beaucoup plus de sécurité, en particulier dans les environnements lors du traitement 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 95% + des requêtes où elles sont applicables. Leur force particulière réside dans le fait que vous avez une application avec une architecture de modèle d'objet solide et une base de données qui fonctionne bien avec ce modèle d'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 pourriez bien avoir une poignée de requêtes qui sont mieux faites à 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 SGBD, le code dépendant de la base de données sera minoritaire. En gardant à l'esprit 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 pour 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 que l'ancienne approche fonctionnait bien sur un très grand projet J2EE (100 années-personnes).
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 de Fowler de l'architecture des applications d'entreprise ont une section sur les modèles d'accès aux données qui fait un assez bon travail de catalogage des différentes approches à ce sujet. Voici quelques exemples de situations où un ORM peut ne pas s'appliquer:
Sur une application avec une base de code héritée substantielle de procédures stockées, vous souhaiterez peut-être utiliser une couche d'accès aux données orientée fonctionnellement (à ne pas confondre avec les langages fonctionnels) pour encapsuler les sprocs sortants. Cela réutilise la conception existante (et donc testée et déboguée) de la couche d'accès aux données et la conception de la base de donné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 Java couches autour de bases de code PL/SQL héritées, ou de recibler des applications clientes riches VB, Powerbuilder ou Delphi avec des interfaces Web.
Une variation est l'endroit où vous héritez d'un modèle de données qui n'est pas nécessairement bien adapté au mappage O-R. Si (par exemple) vous écrivez une interface qui remplit ou extrait des données d'une interface étrangère, il est préférable 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 entre les systèmes est importante, en particulier si vous utilisez des transactions distribuées complexes avec validation en deux phases. Vous devrez peut-être mieux gérer vos transactions qu'un ORM est capable de prendre en charge.
Des applications hautes performances où vous souhaitez vraiment régler l'accès à votre base de données. Dans ce cas, il peut être préférable de travailler à un niveau inférieur.
Les situations où vous utilisez un mécanisme d'accès aux données titulaire comme ADO.Net qui est "assez bon" et qui joue bien avec la plate-forme sont plus avantageux que l'ORM.
Parfois, les données ne sont que des données - il peut être le cas (par exemple) que votre application travaille avec des "transactions" plutôt qu'avec des "objets" et qu'il s'agit d'une vue sensible du domaine. Un exemple de ceci pourrait être un package financier où 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 seul modèle de domaine métier et peut ne pas en savoir beaucoup plus que GL codes, comptes, types de documents et demi une 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 d'objet (au-delà de la structure du grand livre lui-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 n'apportera nécessairement d'avantages 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:
- Tester votre code
- Maintenir votre code
Les solutions à ces problèmes sont les suivantes:
- Rendre votre code testable (en utilisant les principes SOLIDES )
- Écrire des tests automatisés pour autant de code que possible
- Exécutez les tests automatisés aussi souvent que possible
Pour en venir à votre question, les deux objections que vous énoncez ressemblent plus à de l'ignorance qu'à autre chose.
Ne pas pouvoir écrire des requêtes SELECT à la main (ce qui, je présume, 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:
- C'est strictement interdit par la politique de l'entreprise (auquel cas j'irais travailler ailleurs)
- Le projet est extrêmement gourmand en données et l'utilisation de solutions spécifiques aux fournisseurs (comme BulkInsert) est plus logique.
Les rebuffs habituels sur les ORM (NHibernate en particulier) sont:
La vitesse
Il n'y a aucune raison pour que l'utilisation d'un ORM soit plus lente que l'accès aux données codé à la main. En fait, en raison de la mise en cache et des optimisations qui y sont intégrées, cela peut être plus rapide. Un bon ORM produira un ensemble de requêtes reproductibles pour lesquelles vous pouvez 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 d'extraction.
Complexité
En ce qui concerne la complexité, l'utilisation d'un ORM signifie moins de code, ce qui signifie généralement moins de complexité. De nombreuses personnes utilisant un accès aux données manuscrites (ou générées par du code) se retrouvent à écrire leur propre framework 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'amène à l'ensemble du débat ORM, c'est que les mêmes personnes qui prétendent que l'utilisation d'un ORM sera trop difficile/lent/quelles que soient les mêmes personnes qui sont plus qu'heureuses d'utiliser Linq To Sql ou Typed Datasets. Bien que le Linq To Sql soit un grand pas dans la bonne direction, il reste encore des années-lumière derrière certains 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 de (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. Obtenez également un cadre d'injection de dépendances pour faire le câblage.
(Comment ça pour une diatribe?)
Il existe un large éventail de problèmes communs pour lesquels les outils ORM tels que Hibernate sont un envoi divin, et quelques-uns où cela constitue un obstacle. Je ne connais pas assez 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 unmarshalling supportant vos requêtes SQL! Cela peut devenir rapidement désordonné. D'un autre côté, vous savez comment cela fonctionne. Vous pouvez le déboguer. Tout est là dans votre propre couche de persistance, pas enfoui dans les entrailles d'un outil tiers.
Hibernate pourrait être un enfant-affiche de la loi de Spolsky sur les abstractions qui fuient. Sortez un peu des sentiers battus et vous devez connaître le fonctionnement interne profond de l'outil. Cela peut être très ennuyeux lorsque vous savez que vous auriez pu corriger le SQL en quelques minutes, mais que vous passez des heures à essayer de persuader votre outil Dang de générer un SQL raisonnable. Le débogage est parfois un cauchemar, mais il est difficile de convaincre les gens qui n'y sont pas allés.
EDIT: Vous voudrez peut-être examiner iBatis.NET s'ils ne vont pas être tournés autour de NHibernate et qu'ils veulent contrôler leurs requêtes SQL.
EDIT 2: Voici le gros drapeau rouge: "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 jusqu'à présent." Alors, ces développeurs "expérimentés", que sont-ils expérimentés dans le développement? Leur sécurité d'emploi? Il semble que vous fassiez 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. Mets-toi au combat.
J'ai travaillé sur un projet où ne pas utiliser d'ORM a été très réussi. C'était un projet qui
- Doit être horizontalement scalealbe depuis le début
- Devait être développé rapidement
- 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 connaissait notre schéma de partitionnement ...
Donc, dans 90% des projets sur lesquels j'ai travaillé sur un ORM, cela a été d'une aide inestimable. Mais il y a des circonstances très spécifiques où je peux voir que ne pas utiliser un ORM est le meilleur.
Permettez-moi d'abord de dire que les ORM peuvent faciliter votre vie de développement s'ils sont intégrés correctement, 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 performances é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 performance d'écriture lourd (ce qui signifie que nous écrivons des données beaucoup plus que nous ne lisons des données). Dans ces cas, je souhaite profiter des fonctionnalité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 ne pas utiliser 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 une seule ne le fait pas) n'ont pas la possibilité de profiter des avantages spécifiques à 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 Edge où les ORM ne peuvent pas prendre en charge vos besoins et vous devez les contourner pour ces cas.
Pour une application d'entreprise basée sur une base de données non triviale, rien ne justifie vraiment de ne pas utiliser d'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 une certaine perspective dans l'argument, considérez les avantages de l'utilisation d'ADO.NET par rapport à l'écriture du code pour analyser le flux de données tabulaire lui-même.
J'ai vu que l'ignorance de la façon d'utiliser un ORM justifie le dédain d'un développeur pour les ORM Par exemple: un chargement impatient (quelque chose que j'ai remarqué que vous n'avez pas mentionné). Imaginez que vous souhaitiez récupérer un client et toutes ses commandes, ainsi que tous les éléments de détail de la commande. Si vous comptez uniquement sur le chargement paresseux, vous vous éloignerez de votre expérience ORM avec l’opinion: "Les ORM sont lents". Si vous apprenez à utiliser le chargement rapide, vous ferez en 2 minutes avec 5 lignes de code, ce que vos collègues mettront 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 peine 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 cadre 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, cependant, vous obtiendriez 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 me développe professionnellement depuis 23 ans, et l'une des constantes est le mépris du neuf par la vieille école. Les ORM sont à SQL comme le langage C était à Assembly, et vous pouvez parier que les équivalents à C++ et C # sont en route. Une ligne de code de la nouvelle école équivaut à 20 lignes de la vieille école.
Lorsque vous devez mettre à jour 50000000 enregistrements. Définissez un drapeau ou autre chose.
Essayez de le faire en utilisant un ORM sans appelant 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. (Quand vous avez une table très "large"). Ou un résultat scalaire. Les ORM craignent aussi.
MISE À JOUR 2: Il semble que la version bêta d'EF 5.0 promette des mises à jour par lots, mais c'est une très bonne nouvelle (2012, janvier)
Je pense que peut-être 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 votre entités commerciales, mappeurs, passerelles, lazyload et tout ça en C # ... regardez-le ... il a été écrit par une équipe ici en Argentine ...
Je pense que c'est entre le codage de 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 me débrouiller en écrivant 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 j'avais l'habitude de voir (principalement 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 vraiment pratique, et puisque le modèle de données est exprimé en premier en 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 de le compléter avec du SQL manuscrit; mais pour CRUD l'accès est plus que suffisant.
Je ne connais pas NHibernate; mais je suppose que c'est aussi "assez bien" pour la plupart de ce dont vous avez besoin. Mais si d'autres codeurs ne lui font pas confiance; ce sera un suspect principal sur chaque bogue lié aux données, ce qui rendra la vérification plus fastidieuse.
Vous pouvez essayer de l'introduire progressivement sur votre lieu de travail, en vous concentrant d'abord sur les petites applications "évidentes", comme le 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, 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. À la place, l'utilisation de la fonctionnalité d'accès aux données natives de la base de données comme les procédures stockées seraient préférables. Les ORM sont mieux adaptés aux systèmes transactionnels (OLTP).
Je pense qu'il existe de nombreuses bonnes raisons de ne pas utiliser un ORM. Tout d'abord, je suis un développeur .NET et j'aime m'en tenir à ce que le merveilleux cadre .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 donc il y a de bien meilleures chances que tout autre développeur travaillant sur le même projet en cours de route puisse ramasser ce qui est là et l'exécuter. Les capacités d'accès aux données déjà fournies par Microsoft sont assez nombreuses, il n'y a aucune raison de les rejeter.
Je suis un développeur professionnel depuis 10 ans, je dirige plusieurs projets très réussis à plus d'un million de dollars, et je n'ai jamais écrit une seule application qui devait pouvoir passer à n'importe quelle 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é en mesure de faire tout ce dont j'avais besoin. 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 utilisant un ORM comme couche de données. Je pense que c'est mauvais, et quelque chose en plus, j'ai dû apprendre à l'utiliser sans aucune raison. Dans les circonstances incroyablement rares où le client avait besoin de changer de base de données, j'aurais pu facilement retravailler l'intégralité de la base de données en moins de temps que je n'ai passé à tromper les fournisseurs d'ORM.
Honnêtement, je pense qu'il y a une utilisation réelle pour un ORM: si vous créez une application comme SAP qui a vraiment besoin de pouvoir s'exécuter 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 c'est ainsi. Encore une fois, après 10 ans et un nombre incalculable d'applications, cela n'a jamais été un problème.
Sinon, je pense que les ORM sont destinés aux développeurs qui ne comprennent pas moins, c'est mieux, et je pense que plus les outils tiers qu'ils utilisent dans leur application sont cool, meilleure sera leur application. Je vais laisser des choses comme ça aux geeks uber purs et durs pendant que je lance un logiciel beaucoup plus génial en attendant que tout développeur puisse prendre en main et être immédiatement productif.
L'expérience que j'ai eue avec Hibernate est que sa sémantique est subtile, et quand il y a des problèmes, c'est un peu difficile de comprendre ce qui ne va pas sous le capot. Un ami m'a dit que souvent, on commence par Criteria, puis on a besoin d'un peu plus de flexibilité et on a besoin de HQL, et on remarque plus tard 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 tendance à sur-utiliser facilement les mappages/modèles existants, ce qui conduit à un objet avec de nombreux attributs qui ne sont pas initialisé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 aussi, l'objet modèle hibernate 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 veux 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 retrouve 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 autre heure que je n'aurai jamais. Quiconque a utilisé nhibernate, puis fluent 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. Aujourd'hui, je pense que je devrais utiliser moins d'ORM, peut-être créer ou trouver une solution qui permette au minimum les opérations db. 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.
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 ma part, j'ai trouvé les ORM très utiles pour la plupart des applications que j'ai écrites!
/ Asger
Les performances d'exécution sont le seul véritable inconvénient auquel je peux penser, mais je pense que c'est plus qu'un juste compromis pour le temps que l'ORM vous permet de développer/tester/etc. Et dans la plupart des cas, vous devriez pouvoir localiser les goulots d'étranglement des données et 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 "standard" est un manque de flexibilité. Je suis sûr que cela dépend de qui vous allez et de ce que vous devez en faire.
Il y a deux aspects des ORM qui sont inquiétants. Tout d'abord, ils sont du code écrit par quelqu'un d'autre, parfois en source fermée, parfois en open source mais d'une portée énorme. Deuxièmement, ils copient les données.
Le premier problème provoque deux problèmes. Vous comptez sur un code extérieur. Nous le faisons tous, mais le choix de le faire ne doit pas être pris à la légère. Et si elle ne fait pas ce dont vous avez besoin? Quand découvrirez-vous cela? Vous vivez à l'intérieur de la boîte que votre ORM dessine pour vous.
Le deuxième problème est l'une des deux phases de validation. 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 ce n'est pas la chose la plus simple à déboguer.
Je pense que l'utilisation d'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 voudrais parler d'un ORM.
Il n'y a pas d'argument pour # 1 car copier et coller des requêtes et le codage en dur dans le texte ne donne aucune flexibilité, et pour # 2 la plupart des ormes encapsuleront l'exception d'origine, permettront de tracer les requêtes générées, etc.
En ce qui concerne la validation, l'utilisation d'un ORM permettra 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 les choses sont manquées.
EDIT: Je voulais faire un point de plus. Si votre entreprise adopte une stratégie ORM, cela augmente encore sa valeur, car vous développerez des lignes directrices et des pratiques d'utilisation et de mise en œuvre et tout le monde améliorera 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 cela vous fera économiser beaucoup de temps et d'efforts.
Chaque ORM, même "bon", est livré avec un certain nombre d'hypothèses liées aux mécanismes sous-jacents que le logiciel utilise pour faire passer les données entre votre couche d'application et votre magasin de données.
J'ai trouvé que pour une application modérément sophistiquée, le fait de contourner 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 multi-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, le processus d'auto-magie d'un ORM peut être utile.
Sinon, au diable les ORM. Je les considère maintenant comme une mode.