Je suis vraiment déchiré maintenant entre utiliser des mappeurs O / R ou simplement coller à l'accès traditionnel des données. Pour une raison quelconque, chaque fois que j'apporte des mappeurs O / R, des collègues développeurs craignent et parlent de problèmes de performance ou de la manière dont elles sont simplement mauvaises en général. Qu'est-ce que j'oublie ici? Je regarde Linq à SQL et Microsoft Entity Framework. Y a-t-il une base à l'une de ces revendications? Quel genre de choses dois-je compromettre si je veux utiliser une mappeuse O / R. Merci.
8 Réponses :
Le problème que je vois avec beaucoup de mappeurs est que vous obtenez des objets de domaine gonflés, qui sont généralement très couplés au reste de votre cadre d'accès aux données. Nos développeurs se centellent aussi :) Il est tout simplement plus difficile de porter ces objets à une autre technologie d'accès aux données. Si vous utilisez L2S, vous pouvez regarder le code généré. Cela ressemble à un gâchis complet. NHibernate est probablement l'un des meilleurs à cela. Vos entités ignorent complètement votre couche d'accès aux données, si vous les concevez à droite.
DTO est en fait votre passe à travers. Et oui, l'un de leurs inconvénients est l'explosion de classe qu'ils créent.
Je suis d'abord pris mappage d'ormes et couches d'accès aux données de la lecture du livre de Rockford Lhotka, C # Business Objects. Il a passé des années à travailler sur un cadre pour DAL. Bien que sa framed de la boîte soit assez balloise et dans certains cas, surkill, il a d'excellentes idées. Je recommande vivement le livre pour quiconque en regardant des mappeurs Orm. J'ai été influencé par son livre assez pour enlever beaucoup de ses idées et les construire dans mon propre cadre et ma génération de code.
Cela semblera une réponse non liée au début, mais: l'un de mes intérêts latéraux est des avions de chasse de la Seconde Guerre mondiale. Tous les nations combattants (États-Unis, Grande-Bretagne, Allemagne, URSS, Japon, etc.) ont construit un groupe de chasseurs différents pendant la guerre. Certains d'entre eux ont utilisé des moteurs radiaux (P47, Corsair, FW-190, Zero); des moteurs à refroidissement liquide en ligne utilisés (BF-109, Mustang, Yak-7, Spitfire); et certains utilisaient deux moteurs au lieu d'un (P38, DO-335). Certaines mitrailleuses utilisées, certaines canons utilisées et certaines utilisées les deux. Certains étaient même faits de contreplaqué, si vous pouvez imaginer.
À la fin, ils sont tous allés vraiment très vite et entre les mains d'un pilote compétent et expérimenté, ils tireront votre cul recrue dans un rythme cardiaque. J'imagine que beaucoup de pilotes ont volé autour de penser "Oh, cet idiot volait quelque chose avec un moteur radial - je n'ai pas à m'inquiéter de lui du tout". Tout le monde a compris qu'il existait de nombreuses façons différentes d'atteindre l'objectif ultime et que chaque approche avait ses avantages et ses inconvénients particuliers, en fonction des circonstances.
Le débat entre l'ORM et l'accès traditionnel des données est comme celui-ci, et il fallure tout programmeur de devenir compétent avec les deux approches et choisissez l'option qui convient au travail à portée de main.
Découvrez parce que "choisir le bon outil pour le bon travail" est une réponse aussi courante et générique pour toute question de programmation. Au lieu de cela, une meilleure réponse épellerait les situations pour quand un ormes est ou n'est pas approprié. Je voterais une seconde fois parce que l'utilisation d'analogies physiques pour décrire les choix d'architecture de programme tombe toujours en panne une fois que les subtilités sont prises en compte. Temps de formation pilote, coûts de maintenance des aéronefs, utilisation des ressources?
@JFar: Mon point était plus général que la façon dont vous l'avez apparemment pris - que les gens qui disent "Orm est génial et l'autre moyen est une merde complète" (ou inversement) sont simplement stupides. Et ne dites pas «personne ne dit que», parce que les gens disent des choses comme ça tout le temps ici. En ce qui concerne les analogies physiques au logiciel décomposant lorsque vous considérez les détails, je n'aime pas dire «duh», donc je ne le ferai pas.
J'ai lutté avec cette décision pendant une longue période. Je pense que j'étais hésitant pour deux raisons principales. Premièrement, les mappeurs O / R représentaient un manque de contrôle sur ce qui se passait dans une partie critique de l'application et, deuxièmement, parce que tant de fois que j'ai été déçus par des solutions géniales pour le cas de 90% mais misérable pour le dernier dix%. Tout fonctionne pour Select * auprès des auteurs, bien sûr, mais lorsque vous allumez la complexité et que vous avez un système critique élevé, et votre carrière est en ligne, vous sentez que vous devez avoir un contrôle complet pour régler chaque motif de requête et chaque octet sur le fil. La plupart des développeurs, y compris moi, sont frustrés la première fois que l'outil échoue, et nous ne pouvons pas faire ce que nous devons faire, ou notre besoin s'écarte du modèle établi soutenu par l'outil. Je vais probablement être flambé pour mentionner des défauts spécifiques dans des outils, donc je vais le laisser à cela.
Heureusement, Anderson IMES m'a enfin convaincu d'essayer codesmith avec le Modèle de Nettiers . (Non, je ne travaille pas pour eux.) Après plus d'un an, je ne peux pas croire que nous ne l'avons pas fait plus tôt. Mon équipe utilise Visual Studio DB Pro et sur chaque enregistrement Notre intégration continue Build dépose un nouvel ensemble d'ensembles de couche d'accès aux données. Cela gère tous les trucs communs et faibles à risque automatiquement, mais nous pouvons toujours écrire des Sprates personnalisées pour les bits difficiles et les avoir inclus comme méthodes sur les classes générées et nous pouvons également personnaliser les modèles pour le code généré. Je recommande vivement cette approche. Il peut également y avoir d'autres outils permettant également ce niveau de contrôle, et il existe un nouveau modèle de code de code appelé plinqo qui utilise LINQ vers SQL sous le capot. Nous n'avons pas encore été examiné (n'ont pas besoin de), mais cette approche globale a beaucoup de mérite.
jerry
Il n'y a pas de réponse simple à cela puisque chaque fournisseur d'ormes aura ses propres plus et minus particuliers. Certaines solutions ORM sont plus flexibles que d'autres. L'ONUS est sur le développeur pour les comprendre avant d'en utiliser un.
Cependant, prenez Linqtosql - si vous êtes sûr que vous n'aurez pas besoin d'éteindre du serveur SQL, cela résout un grand nombre de problèmes courants observés dans les mappeurs Orm. Il vous permet d'ajouter facilement des procédures stockées (en tant que méthodes statiques), de sorte que vous n'êtes donc pas limité au SQL généré. Il utilise une exécution différée, de sorte que vous puissiez chaîner efficacement les requêtes. Il utilise des classes partielles pour vous permettre d'ajouter facilement une logique personnalisée aux classes générées sans avoir à vous soucier de ce qui se passe lorsque vous les générez. Il n'y a pas non plus que rien n'empêche d'utiliser Linq pour créer votre propre dal, abstrait dal - il accélère simplement le processus. La principale chose, cependant, c'est que cela atténue l'édium et le temps requis pour créer une couche de crud de base.
Mais il y a des descentes aussi. Il y aura un couplage serré entre vos tables et vos classes, il y aura une légère chute de performances, vous pouvez parfois générer des requêtes qui ne sont pas aussi efficaces que prévu. Et vous êtes lié à SQL Server (bien que d'autres technologies ORM soient de base de données agnostique).
Comme je l'ai dit, l'essentiel est d'être conscient des avantages et des inconvénients avant d'épingler vos couleurs à une méthodologie particulière.
La plupart des autres outils O / RM permettent de cartographier les Sprates tout aussi facile. Nommer peu: (n) hibernate et entitéframework. Microsoft a également cessé de travailler sur Linq2SQL afin que nous soyons à peu près bloqué avec la mise en œuvre actuelle ...
Arrêté de travailler sur Linq2SQL? Damieng.com/blog/2009/ 06/01 / LINQ-TO-SQL-Changements-in-Net-40
Outils O / RM conçus pour effectuer très bien dans la plupart des situations. Il mettra en cache des entités pour vous, il exécutera des requêtes en vrac, il dispose d'un accès optimisé à très bas niveau à des objets de manière plus rapide que d'attribuer manuellement des valeurs aux propriétés, ils vous donnent un moyen très facile d'intégrer des variations d'une programmation orientée orientée en utilisant Techniques modernes telles que les intercepteurs, il gérera l'état de l'entité pour vous et aidera à résoudre les conflits et de nombreux autres.
Les inconvénients de cette approche résident généralement par manque de compréhension de la façon dont les choses fonctionnent à un niveau très bas. Le problème le plus classique est "Select n + 1" ( lien ).
J'ai travaillé avec NHibernate depuis 2,5 ans maintenant, et je découvre toujours quelque chose de nouveau à ce sujet presque quotidiennement ...
Bien. Dans la plupart des cas.
Le bénéfice de la productivité de l'utilisation d'un orj, l'emportera dans la plupart des cas la perte de contrôle de la manière dont les données sont accessibles.
Il n'y a pas que beaucoup qui éviteraient C #, afin de programmer le mystère ou l'assemblage, bien que cela leur donnerait plus de contrôle.
+1 En raison du mot clé: productivité . J'ai mis en place une sorte de système CRM avec une base de données complexe dans MySQL. Je ne peux pas imaginer avoir à faire tout le mappage manuellement à chaque fois les exigences changées ... et cela s'est passé comme 50 fois.
Cela dépend vraiment de la situation.
Je suis allé d'une entreprise qui a utilisé un orm ajusté à une entreprise qui n'a pas utilisé de ORM et a écrit des requêtes SQL tout le temps. Quand j'ai posé des questions sur l'utilisation d'un orj pour simplifier le code, j'ai eu ce look vide au visage suivi de tous les négatifs de celui-ci:
sur un sur
Eh bien, après y avoir travaillé pendant quelques semaines, j'avais remarqué que:
Après avoir signalé la majeure partie de cela, ils ont écrit un "DBO" parce que la personne ne voulait pas appeler une ormission. Ils ont décidé d'en écrire un de zéro au lieu de modifier un.
En outre, beaucoup des arguments proviennent de l'ignorance contre les ormes que je ressens. Chaque orj que j'ai vu permet de faire des requêtes personnalisées et même de suivre les conventions de l'ORM, vous pouvez écrire des requêtes très complexes et détaillées et sont normalement plus lisibles pour l'homme. En outre, ils ont tendance à être très secs, vous leur donnez votre schéma, et ils encrillent le reste, jusqu'à la cartographie de la relation.
Les ormes modernes ont beaucoup d'outils pour vous aider, comme les scripts de migration, plusieurs types de DB accessibles aux mêmes objets afin que vous puissiez tirer parti des avantages des DB NOSQL et SQL. Mais vous devez choisir le bon orj pour votre projet si vous allez en utiliser un.
J'aime ces Devs qui consacrent 80% du projet perfectionnant une main à la main dal pour «raisons de performance», puis cracher 100k de Viewstate gonflée à l'utilisateur final ... Priorités
Devrait-il être wiki communautaire?
Cette question a été posée plusieurs fois. Faites simplement une recherche sur 'orm' et vous trouverez un groupe.