Quels sont les problèmes potentiels liés au mélange de Fluent NHibernate et Dapper-dot-net?

.net dapper fluent-nhibernate

Question

Je dois supporter un projet utilisant Fluent NHibernate depuis quelques années maintenant et j'en suis vraiment fatigué. Je veux utiliser Dapper-dot-net ( https://github.com/StackExchange/dapper-dot-net ) pour aller de l’avant, mais certains membres de mon équipe sont opposés à l’utilisation en raison du souci de mélanger deux frameworks ORM en un seul projet.

Est-ce que leurs préoccupations sont justifiées? Quelqu'un at-il de l'expérience dans ce domaine qui pourrait indiquer pourquoi NHibernate et Dapper (ou d'autres cadres d'ORM) ne peuvent pas exister ensemble sur le même projet?

Merci,

Réponse acceptée

Tout d'abord, je n'ai pas d'expérience directe en matière de combinaison de Fluent NHibernate (FNH) et de Dapper dans le même projet, gardez donc cela à l'esprit! Cependant, j'ai utilisé FNH, Entity Framework et Dapper indépendamment dans des projets distincts et, ayant choisi Dapper pour le dernier projet précisément en raison de sa simplicité et que je voulais éviter un ORM plus lourd, je peux personnellement apprécier l'attrait de Dapper pour plus de fonctionnalités alternatives riches. Bien qu'il n'y ait aucune raison pour que les deux cana € ™ t existent dans le même projet en tant que tel, je pense que votre équipe sont parfaitement raison de soulever des objections au sujet de l' introduction d'une autre technologie d'accès aux données dans le même projet (mais si ces préoccupations l' emportent sur les avantages de déplacement Dapper dépend bien sûr des exigences particulières de vos équipes).

Quelques considérations / préoccupations techniques immédiates qui viendraient à l'esprit:

  • Changement de contexte mental entre un ORM complet et un wrapper fin autour d'ADO.NET. Bien que dans des cas triviaux remplaçant:

    Query (a => a.Id == id && a.Active == true) ...

    avec

    "WHERE id = @Id AND active = true" ...

    ne va pas être un énorme saut mental, je peux comprendre que lors du débogage, basculer entre une requête qui utilise FNH à une autre qui utilise du SQL brut et vice versa ne sera probablement pas l'expérience la plus agréable pour votre équipe en particulier avec plus requêtes complexes.

  • Prévoyez-vous de retourner / consommer le même ensemble d'entités de domaine avec vos requêtes Dapper qu'aujourd'hui? Si tel est le cas, y aura-t-il des problèmes si vous devez répliquer des fonctionnalités telles que le chargement différé (que vous utilisez peut-être actuellement mais qui ne sera pas fourni dans Dapper) et les relations d'entité?

  • Dapper exigera évidemment que vous écriviez à la main vos requêtes SQL. Si FNH a été choisi parce que votre équipe préfère activement écrire des requêtes de style LINQ sur du SQL brut ou, plus important encore, parce qu'elles ne sont pas familiarisées avec SQL, l'introduction de Dapper imposera également à votre équipe la courbe d'apprentissage de SQL.

  • Dapper ne fournira aucune vérification de vos requêtes lors de la compilation. Par conséquent, les modifications apportées à vos entités qui seraient normalement prises en compte dans les mappages et requêtes courants, sur lesquels votre équipe peut s’appuyer, ne seront pas signalées.

Une préoccupation plus générale serait de savoir comment vous envisagez de combiner les deux à plus long terme. Je ne suis pas familier avec votre projet particulier et avec la fonctionnalité FNH que vous avez employée. Par conséquent, si vous envisagez d’utiliser uniquement Dapper, en laissant votre code existant tel quel, vous devrez probablement retenir quelqu'un qui a expertise en FNH si des requêtes complexes faisant un usage intensif de la fonctionnalité FNH doivent être fortement remaniées ou débogées.


Réponse populaire

Juste pour clarifier: je pense que ce que vous demandez est d'utiliser nHibernate et Dapper ensemble dans le même projet. (Fluent nHibernate n'est pas ORM, c'est une bibliothèque qui aide à la cartographie).

J'utilise nHibernate + FNH depuis des années et dans mes deux derniers projets Web, j'ai introduit Dapper.net car je cherchais à améliorer les performances en lecture. Mes projets sont construits à l'aide de CQS, ce qui me permet d'utiliser nHibernate pour les écritures (commandes) et Dapper.net pour les lectures (requêtes). Cela me donne le pouvoir de nHibernate et le côté lecture rapide flamboyant.

Des problèmes que votre équipe pourrait avoir avec les deux:

  • l'architecture du projet n'est pas adaptée / difficile à faire changer
  • nécessite un travail supplémentaire pour écrire SQL manuellement
  • nécessite un travail supplémentaire pour la cartographie des entités ou la création et la cartographie des DTO
  • il n'y a pas de réel avantage à l'introduire

Si vous voulez le faire simplement parce que vous en avez assez de nHibernate, ils ont de bonnes raisons de s’inquiéter.



Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi