Migration d'application vers Dapper.net depuis EF4

c# dapper entity-framework-4 wpf

Question

Je travaille sur une grande application WPF avec Entity Framework4, maintenant le client demande la migration de l'application de EF4 vers Dapper.net. Je ne suis pas sûr de la faisabilité et du gain commercial de cette tâche de migration car les fonctionnalités suivantes de EF4 sont manquantes dans Dapper:

  • Suivi des modifications
  • Chargement paresseux
  • Désireux d'aller chercher
  • Cascades
  • Carte d'identité
  • Unité de suivi du travail

S'il vous plaît me suggérer sur ceci ou si d'autres micro ORM existent pour les applications WPF.

Réponse acceptée

EF4 et Dapper sont des outils différents avec des objectifs différents et des fonctionnalités différentes. En effet, il est assez courant de voir Dapper et des outils comme EF fonctionner côte à côte (parfois même contre le même modèle d’objet) - en particulier lorsque vous n’utilisez pas tout ce que vous avez répertorié dans les puces; Par exemple, beaucoup de code d'affichage (affichage des pages à l'utilisateur, etc.) a tendance à ne pas utiliser ces éléments. Pour le code en lecture seule, il peut parfois être très simple de basculer dans une implémentation dapper - il suffit d'écrire du code SQL et c'est parti.

Toutefois! En ce qui concerne le code qui n'utilise les fonctionnalités que vous avez mentionné, ce changement est bien plus fondamentale; ce n'est pas vraiment "migrer" autant que "réimplémenter". Sans le suivi des modifications, votre propre code devrait être plus clair sur les opérations exécutées par chaque processus. C'est en fait une bonne chose, IMO, mais ce n'est pas trivial de le convertir dans une base de code existante. Si vous partez de zéro (ou: de nouvelles tables, etc. dans un modèle existant), c'est généralement très facile.

Personnellement, l'approche que je prendrais ici serait d' abord d'examiner vos opérations de récupération de données clés (en particulier les requêtes complexes, les requêtes complexes ou les gros volumes) - et de déterminer si elles peuvent être remplacées par des opérations de lecture basées sur les données; surtout en lecture seule. Vous pouvez probablement obtenir des gains énormes avec un minimum de travail. Le profilage serait important et des outils tels que le mini-profileur pourraient être utiles. Personnellement, je ne commencerais pas à déchirer une couche de données existante et existante - cela semble inventer du travail pour le plaisir; et ce sera compliqué (échanger un ORM n'est pas une chose triviale).

Je voudrais toutefois réfléchir sérieusement à la mise à jour vers une version plus récente de EF; p

(oh, et si c'est important: je suis l'auteur principal et le responsable du dapper)


Réponse populaire

À mon avis, la question cruciale est de savoir pourquoi votre client veut que vous migriez ce projet vers un autre cadre.

Si elle souhaite que vous effectuiez cette migration en raison des performances médiocres de certaines fonctionnalités ou modules, vous pouvez adopter l'approche de Marc et migrer uniquement les parties critiques de votre système.

Dans certains projets de mon entreprise, nous utilisons Dapper côte à côte avec des trucs NHibernate complets et cela fonctionne vraiment. Surtout dans le reporting et le traitement par lots lorsque vous souhaitez probablement appeler des procédures stockées au lieu de simples opérations CRUD.

Si vous décidez de suivre ce chemin, je vous suggère d’utiliser le modèle "Unit of work" pour permettre à EF et Dapper de travailler sur la même connexion de base de données (j’ai déjà parlé de ce sujet il ya quelque temps).

Bien sûr, vous devez garder à l’esprit les différences techniques telles que Dapper (contrairement aux ORM «complets» comme EF ou NH) n’a pas de concept de session et que les objets «sales» modifiés par EF doivent être lus par Dapper uniquement après vidage des modifications à la base de données.



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