Sont là de bonnes raisons de ne pas utiliser un ORM?

Question

Pendant mon apprentissage, j'ai utilisé NHibernate pour certains des petits projets dont j'avais le plus codé et conçu sur mon propre. Maintenant, avant de commencer certains plus gros projet, le débat est la façon de concevoir l'accès aux données et de savoir si ou de ne pas utiliser un ORM couche. Comme je suis encore dans mon apprentissage, et me considère encore comme un débutant dans l'entreprise de programmation, je n'ai pas vraiment d'essayer de pousser à mon avis, qui est que l'utilisation d'un object relational mapper à la base de données peut faciliter le développement de beaucoup. Les autres codeurs dans l'équipe de développement sont beaucoup plus expérimentés que moi, donc je pense que je vais juste faire ce qu'ils disent. :-)

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

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

Alors, bien sûr, je pourrais construire ma couche d'accès aux données avec beaucoup d' SELECTs, etc, mais ici je m'ennuie de l'avantage de jointures automatiques, lazy-chargement des classes de proxy et d'un moindre effort de maintenance si une table obtient une nouvelle colonne ou d'une colonne devient renommé. (Mise à jour de nombreux SELECT, INSERT et UPDATE des requêtes contre la mise à jour de la cartographie config et éventuellement remanier les classes d'affaires et de l'Otd.)

Aussi, à l'aide de NHibernate vous pouvez rencontrer des problèmes imprévus si vous ne connaissez pas le cadre très bien. Qui pourrait être, par exemple, de faire confiance à la Table.hbm.xml lorsque vous définissez une longueur de la chaîne pour être validé automatiquement. Cependant, je peux aussi imaginer bugs similaires dans un "simple" SqlConnection de requête de base de données de la couche d'accès.

Enfin, ce sont ces arguments mentionnés ci-dessus vraiment une bonne raison de ne pas utiliser un ORM pour un non-trivial base de données, d'applications d'entreprise? Sont il y a probablement d'autres arguments qu'ils/j'ai peut-être raté?

(Dois-je ajouter que je pense que c'est comme le premier "gros" .NET/C# en fonction de l'application qui nécessitent un travail d'équipe. Les bonnes pratiques, qui sont considérées comme tout à fait normal sur un Débordement de Pile, tels que les tests unitaires ou d'intégration continue, intégration continue sont non-existant ici jusqu'à maintenant.)

Answer 1

La réponse courte est oui, il y a vraiment de bonnes raisons. Comme une question de fait, il y a des cas où vous ne pouvez pas utiliser un ORM.

Affaire au point, je travaille pour une grande entreprise de l'institution financière et que nous avons à suivre beaucoup de directives en matière de sécurité. Pour respecter les règles et règlements qui sont mis sur nous, le seul moyen de transmettre des vérifications 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, il ne l'est pas. À l'aide d'un outil ORM moyen de l'outil/le développeur peut insérer, de sélectionner, de mettre à jour ou supprimer tout ce qu'il ou elle veut. Les procédures stockées de fournir beaucoup plus de sécurité, en particulier dans les environnements lorsque vous traitez avec les données du client. Je pense que c'est la principale raison de considérer. De sécurité.

Answer 2

Le sweet spot de l'Orm

Orm sont utiles pour l'automatisation de l'95%+ de requêtes où elles sont applicables. Leur force particulière est l'endroit où vous avez une application avec un solide modèle d'objet de l'architecture et une base de données qui joue bien avec ce modèle d'objet. Si vous êtes en train de faire une nouvelle version et avoir de solides compétences en matière de modélisation, dans votre équipe, vous aurez probablement obtenir de bons résultats avec un ORM.

Vous avez peut-être une poignée de requêtes qui sont fait à la main. Dans ce cas, n'hésitez pas à écrire quelques procédures stockées pour gérer cela. Même si vous avez l'intention de port de votre application sur plusieurs SGBD plates-formes de la base de données de code dépendant d'être une minorité. En gardant à l'esprit que vous aurez besoin de tester votre application sur n'importe quel plate-forme sur laquelle vous avez l'intention de le soutenir, un petit peu plus d'effort de portage pour certaines procédures stockées ne va pas faire beaucoup de différence pour votre coût total de possession. Pour une première approximation, 98% portable est 100% portable, et beaucoup mieux que alambiqué ou peu performante des solutions pour contourner les limites d'un ORM.

J'ai vu la première approche fonctionne bien sur un très large (100 du personnel-années) projet J2EE.

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

Dans d'autres cas, il peut y avoir des approches qui conviennent à l'application de mieux qu'un ORM. Fowler Modèles d'Architecture d'Applications d'Entreprise a une section sur l'accès aux données des modèles qui fournit un assez bon travail de catalogage des approches différentes. Quelques exemples que j'ai vu des situations où l'ORM peuvent ne pas être applicables sont les suivants:

• Sur une application avec un legs important de la base de code de procédures stockées, vous souhaiterez peut-être utiliser une fonctionnellement orientée (à ne pas confondre avec les langages fonctionnels) couche d'accès aux données pour envelopper le titulaire sprocs. Cette ré-utilise l'existant (et donc testés et corrigés) couche d'accès aux données et de conception de base de données, qui représente souvent assez considérable de développement et de test d'effort, et évite d'avoir à migrer les données vers un nouveau modèle de base de données. Il est souvent une bonne manière d'emballage Java couches autour de l'héritage de code PL/SQL bases, ou de re-ciblage client riche VB, Powerbuilder ou Delphi applications avec des interfaces web.

• Une variante est l'endroit où vous héritez d'un modèle de données qui n'est pas forcément bien adapté à la Ou de cartographie. Si (par exemple) vous écrivez une interface qui remplit ou d'extraire des données à partir d'un étranger interface, il peut être préférable de travailler directement avec la base de données.

• Applications financières ou d'autres types de systèmes où la croix-système de l'intégrité des données est important, surtout si vous êtes en utilisant un complexe de transactions distribuées avec de validation à deux phases. Vous pouvez avoir besoin de s'immiscer dans vos transactions de mieux qu'un ORM est capable de supporter.

• Haute performance des applications où vous voulez vraiment de régler votre base de données access. Dans ce cas, il peut être préférable de travailler à un niveau inférieur.

• Les Situations où vous êtes en utilisant pour le titulaire de l'accès aux données comme mécanisme de ADO.Net c'est "assez bon" et de jouer gentiment avec la plate-forme est de plus bénéfique que l'ORM apporte.

• Parfois, les données ne sont que des données - c'est peut-être le cas (par exemple) que votre application fonctionne avec des "transactions" plutôt que des "objets", et que c'est un bon vue sur le domaine. Un exemple de cela pourrait être un financials paquet où vous avez transactions avec configurables champs d'analyse. Alors que l'application elle-même peut être construit sur un O-O plate-forme, il n'est pas lié à un seul modèle de domaine d'entreprise et peuvent ne pas être au courant de beaucoup plus de codes comptables, les comptes, les types de document et une demi-douzaine de champs d'analyse. Dans ce cas, la demande n'est pas au courant d'un modèle de domaine d'entreprise en tant que telle et d'un modèle d'objet (au-delà de la comptabilité de la structure elle-même) n'est pas applicable à la demande.

Answer 3

Tout d'abord - l'utilisation d'un ORM ne fera pas votre code plus facile à tester, ni nécessairement fournir tous les avantages de l'Intégration Continue scenerio.

Dans mon expérience, lors de l'utilisation d'un ORM peut augmenter la vitesse de développement, les plus grands problèmes à résoudre sont les suivantes:

1. Test de votre code
2. Le maintien de votre code

Les solutions sont:

1. Rendre votre code testable (à l'aide de SOLIDES principes)
2. Écrire des tests automatisés pour autant de code que possible
3. Exécuter des tests automatisés aussi souvent que possible

Pour en venir à votre question, les deux objections vous liste ressemblent plus à de l'ignorance qu'autre chose.

Ne pas être capable d'écrire des requêtes SELECT à la main (ce qui, je présume, est pourquoi le copier-coller est nécessaire), ce qui semble indiquer qu'il y a un besoin urgent pour certains SQL de formation.

Il y a deux raisons pour lesquelles je n'avais pas utiliser un ORM:

1. Il est strictement interdit par la politique de la société (dans ce cas, je serais aller travailler ailleurs)
2. Le projet est extrêmement intensif de données et l'utilisation de fournisseur de solutions spécifiques (comme BulkInsert) a plus de sens.

L'habitude rebuffades sur Orm (NHibernate en particulier) sont:

1. Vitesse

   Il n'ya aucune raison pourquoi l'utilisation d'un ORM serait plus lente que la part codé d'Accès aux Données. En fait, en raison de la mise en cache et optimisations construit en elle, il peut être plus rapide. Une bonne ORM va produire un ensemble reproductible de requêtes pour lesquelles vous pouvez optimiser votre schéma. Une bonne ORM permettra également à l'efficacité de la recherche de données associées à l'aide de diverses stratégies de chargement.

2. La complexité

   En ce qui concerne la complexité, à l'aide d'un ORM signifie moins de code, ce qui signifie généralement moins de complexité. Beaucoup de personnes utilisant écrite à la main (ou code généré) l'accès aux données se retrouvent de la rédaction de leur propre cadre de "bas niveau" des bibliothèques d'accès aux données (comme la rédaction des méthodes d'assistance pour les ADO.Net). Ces assimiler à plus de complexité, et, pire encore, ils sont rarement bien documenté, ou bien testé.
   Si vous êtes à la recherche spécifiquement à NHibernate, puis des outils comme Couramment NHibernate et Linq to NHibernate aussi adoucir la courbe d'apprentissage.

La chose qui me met sur l'ensemble de l'ORM débat, c'est que les mêmes personnes qui prétendent que l'utilisation d'un ORM va être trop dur/lent/quelles qu'en soient les mêmes personnes qui sont plus qu'heureux à l'aide De Linq to Sql ou Typés. Tandis que le Linq to Sql est un grand pas dans la bonne direction, c'est encore à des années lumière derrière où une partie de l'open source Formulaires sont. Toutefois, les cadres que pour les deux Datasets Typés et Linq to Sql est toujours extrêmement complexe, et l'aide à aller trop loin de la (Table=Classe) + (CRUD de base) est bêtement difficile.

Mon conseil est que si, à la fin de la journée, vous ne pouvez pas obtenir un ORM, alors assurez-vous que votre accès aux données est séparée du reste du code, et que vous vous suivez la " bande Des Quatre conseils de codage à une interface. En outre, obtenir une Injection de Dépendance cadre pour faire le câblage.

(Comment est-ce pour un coup de gueule?)

Answer 4

Il ya un large éventail de problèmes communs pour lesquels des outils ORM comme Hibernate est un dieu-envoyer, et quelques-unes où il est un obstacle. Je ne connais pas assez bien votre projet, afin de savoir qui il est.

L'un des Hibernate points forts est que vous obtenez de dire des choses que 3 fois: chaque propriété est mentionné dans la classe, l' .hbm.xml fichier et la base de données. Avec des requêtes SQL, vos propriétés sont dans la classe, la base de données, les instructions select, insert, update, delete, et tous les rassemblement et de l'unmarshalling code de soutenir vos requêtes SQL! Cela peut dégénérer rapidement. D'autre part, vous savez comment cela fonctionne. Vous pouvez déboguer. Tout est là, dans votre propre couche de persistance, et non pas enfoui dans les entrailles d'un outil 3ème partie.

Hibernate pourrait être une affiche-enfant pour Spolsky du Droit des Abstractions qui fuient. Obtenir un peu hors des sentiers battus, et vous avez besoin de savoir profondément fonctionnement interne de l'outil. Il peut être très ennuyeux quand vous savez que vous pourriez avoir fixé le SQL en quelques minutes, mais au lieu de passer des heures à essayer de l'amadouer votre dang outil en générant raisonnable SQL. Le débogage est parfois un cauchemar, mais il est difficile de convaincre des gens qui n'ont pas été là.

EDIT: Vous voudrez peut-être regarder dans iBatis.NET si elles ne sont pas va être tourné autour de NHibernate et ils veulent contrôler les requêtes SQL.

EDIT 2: Voici le grand drapeau rouge, mais: "les Bonnes pratiques, qui sont considérées comme tout à fait normal sur un Débordement de Pile, tels que les tests unitaires ou d'intégration continue, intégration continue sont non-existant ici jusqu'à maintenant." Donc, ces "expérimenté" les développeurs, quelles sont-elles connu dans le développement? La sécurité de leur emploi? Il semble que vous pourriez être parmi les personnes qui ne sont pas particulièrement intéressés dans le champ, afin de ne pas les laisser tuer votre intérêt. Vous devez être l'équilibre. Mettre en place un combat.

Answer 5

Il y a eu une explosion de la croissance avec de l'Orm au cours des dernières années et vos collègues plus expérimentés peuvent encore être pensée en la "tous à la base de données devrait être par une procédure stockée" mentalité.

Pourquoi un ORM rendre les choses plus difficiles à déboguer? Vous obtiendrez le même résultat s'il s'agit d'une procédure stockée ou de l'ORM.

Je suppose que le seul préjudice réel que je peux penser avec un ORM, c'est que le modèle de sécurité est un peu moins souple.

EDIT: je viens de re-lire votre question et il semble qu'ils sont la copie et le collage requêtes dans inline sql. Cela rend le modèle de sécurité de la même façon qu'un ORM, donc il n'y aurait absolument aucun avantage par rapport à cette approche sur un ORM. Si elles sont à l'aide de unparametrized requêtes alors il serait effectivement un risque pour la sécurité.