Pourquoi devriez-vous utiliser un ORM?
Si vous deviez motiver les "pros" de la raison pour laquelle vous utiliseriez un ORM pour la direction/le client, quelles en seraient les raisons?
Essayez de garder une raison par réponse afin que nous puissions voir ce qui est voté comme les meilleures raisons
Rendre l'accès aux données plus abstrait et portable. Les classes d'implémentation ORM savent comment écrire du SQL spécifique au fournisseur, vous n'avez donc pas à le faire.
La raison la plus importante d'utiliser un ORM est que vous puissiez avoir un modèle commercial riche et orienté objet et être toujours en mesure de le stocker et d'écrire rapidement des requêtes efficaces sur une base de données relationnelle. De mon point de vue, je ne vois aucun avantage réel qu'un bon ORM vous offre par rapport à d'autres DAL générés autres que les types avancés de requêtes que vous pouvez écrire.
Un type de requête auquel je pense est une requête polymorphe. Une simple requête ORM peut sélectionner toutes les formes de votre base de données. Vous obtenez une collection de formes en arrière. Mais chaque instance est un carré, un cercle ou un rectangle selon son discriminateur.
Un autre type de requête serait celui qui récupère avec impatience un objet et un ou plusieurs objets ou collections associés dans un seul appel de base de données. par exemple. Chaque objet de forme est renvoyé avec ses collections de sommets et de côtés remplies.
Je suis désolé d'être en désaccord avec tant d'autres ici, mais je ne pense pas que la génération de code soit une raison suffisante en soi pour aller avec un ORM. Vous pouvez écrire ou trouver de nombreux bons modèles DAL pour les générateurs de code qui n'ont pas la surcharge conceptuelle ou de performance que les ORM font.
Ou, si vous pensez que vous n'avez pas besoin de savoir comment écrire du bon SQL pour utiliser un ORM, encore une fois, je ne suis pas d'accord. Il est peut-être vrai que du point de vue de l'écriture de requêtes uniques, il est plus facile de s'appuyer sur un ORM. Mais, avec les ORM, il est beaucoup trop facile de créer des routines peu performantes lorsque les développeurs ne comprennent pas comment leurs requêtes fonctionnent avec l'ORM et le SQL dans lesquels elles se traduisent.
Avoir une couche de données qui fonctionne avec plusieurs bases de données peut être un avantage. Ce n'est pas celui sur lequel j'ai dû compter souvent.
En fin de compte, je dois répéter que, selon mon expérience, si vous n'utilisez pas les fonctionnalités de requête plus avancées de votre ORM, il existe d'autres options qui résolvent les problèmes restants avec moins d'apprentissage et moins de cycles de processeur.
Oh oui, certains développeurs trouvent que travailler avec les ORM est amusant, donc les ORM sont également bons du point de vue de la satisfaction de vos développeurs. =)
Accélérer le développement. Par exemple, éliminer le code répétitif comme le mappage des champs de résultats de requête aux membres d'objet et vice-versa.
Prise en charge de OO encapsulation des règles métier dans votre couche d'accès aux données. Vous pouvez écrire (et déboguer) des règles métier dans le langage de préférence de votre application, au lieu des langages de déclenchement et de procédure stockée maladroits.
Génération de code passe-partout pour les opérations CRUD de base. Certaines infrastructures ORM peuvent inspecter directement les métadonnées de base de données, lire des fichiers de mappage de métadonnées ou utiliser des propriétés de classe déclaratives.
Vous pouvez facilement passer à différents logiciels de base de données car vous développez vers une abstraction.
Bonheur de développement, OMI. ORM résume un grand nombre de choses que vous devez faire en SQL. Il maintient votre base de code simple: moins de fichiers source à gérer et les modifications de schéma ne nécessitent pas des heures d'entretien.
J'utilise actuellement un ORM et cela a accéléré mon développement.
Pour que votre modèle d'objet et votre modèle de persistance correspondent.
Pour minimiser la duplication de requêtes SQL simples.
La raison pour laquelle j'y cherche est d'éviter le code généré à partir des outils DAL de VS2005 (mappage de schéma, TableAdapters).
Le DAL/BLL que j'ai créé il y a plus d'un an fonctionnait bien (pour ce que je l'avais construit) jusqu'à ce que quelqu'un d'autre commence à l'utiliser pour profiter de certaines des fonctions générées (dont je ne savais pas qu'elles étaient là)
Il semble qu'il fournira une solution beaucoup plus intuitive et plus propre que la solution DAL/BLL de http://wwww.asp.net
Je pensais à créer mon propre générateur de code SQL Command C # DAL, mais l'ORM ressemble à une solution plus élégante
Compilation et test de requêtes.
Au fur et à mesure que l'outillage des ORM s'améliore, il est plus facile de déterminer plus rapidement l'exactitude de vos requêtes grâce aux erreurs de temps de compilation et aux tests.
La compilation de vos requêtes aide les développeurs à trouver les erreurs plus rapidement. Droite? Droite. Cette compilation est rendue possible parce que les développeurs écrivent maintenant des requêtes dans du code en utilisant leurs objets ou modèles métier au lieu de simplement des chaînes de SQL ou d'instructions SQL.
Si vous utilisez les modèles d'accès aux données corrects dans .NET, il est facile de tester par unité votre logique de requête dans les collections de mémoire. Cela accélère l'exécution de vos tests car vous n'avez pas besoin d'accéder à la base de données, de configurer des données dans la base de données ou même de faire tourner un contexte de données complet. [EDIT] Ce n'est pas aussi vrai que je pensais que c'était comme unité les tests en mémoire peuvent présenter défis difficiles à surmonter. Mais je trouve toujours ces tests d'intégration plus faciles à écrire que les années précédentes. [/ EDIT]
C'est certainement plus pertinent aujourd'hui qu'il y a quelques années lorsque la question a été posée, mais cela ne peut être le cas que pour Visual Studio et Entity Framework où mon expérience se trouve. Branchez votre propre environnement si possible.
Abstenez le sql loin 95% du temps afin que tout le monde dans l'équipe n'ait pas besoin de savoir comment écrire des requêtes spécifiques à une base de données super efficace.
Je pense qu'il y a beaucoup de bons points ici (portabilité, facilité de développement/maintenance, se concentrer sur OO modélisation commerciale, etc.), mais lorsque vous essayez de convaincre votre client ou votre gestion, tout se résume à combien d'argent vous économiserez en utilisant un ORM.
Faites quelques estimations pour des tâches typiques (ou même des projets plus importants qui pourraient être lancés) et vous obtiendrez (espérons-le!) Quelques arguments pour le changement qui sont difficiles à ignorer.
Je pense qu'un inconvénient est que l'ORM aura besoin d'une mise à jour dans votre POJO. principalement lié au schéma, à la relation et à la requête. donc le scénario où vous n'êtes pas supposé apporter des modifications dans les objets du modèle, pourrait être parce qu'il est partagé entre plus que sur le projet ou le client et le serveur n/b. dans de tels cas, vous devrez le diviser en deux niveaux, ce qui nécessitera des efforts supplémentaires.
je suis un développeur Android et comme vous le savez, les applications mobiles ne sont généralement pas de grande taille, donc cet effort supplémentaire pour séparer le modèle pur et le modèle affecté par orm ne semble pas valoir la peine.
je comprends que cette question est générique. mais les applications mobiles entrent également dans le cadre générique.
Niveaux .net utilisant des modèles de code smith
http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1
Pourquoi coder quelque chose qui peut aussi être généré.
les convaincre combien de temps/argent vous économiserez lorsque les changements arriveront et vous n'avez pas à réécrire votre SQL puisque l'outil ORM le fera pour vous