Alors que je creuse plus profondément dans le DbContext, DbSet et les interfaces associées, je me demande pourquoi vous auriez besoin de mettre en œuvre un référentiel «générique» distinct autour de ces implémentations?
Il semble que DbContext et IDbSet font tout ce dont vous avez besoin et incluent l '«unité de travail» dans DbContext.
Est-ce que je manque quelque chose ici ou semble-t-il que les gens aiment ajouter une autre couche de dépendance sans raison.
Réponses:
Vous avez vraiment raison.
DbContextest une implémentation du modèle d'unité de travail etIDbSetest une implémentation du modèle de référentiel.Les référentiels sont actuellement très populaires et surutilisés. Tout le monde les utilise simplement parce qu'il existe des dizaines d'articles sur la création d'un référentiel pour le cadre d'entité, mais personne ne décrit réellement les défis liés à cette décision.
Les principales raisons d'utiliser le référentiel sont généralement:
La première raison est une sorte de pureté architectonique et une excellente idée que si vous rendez vos couches supérieures indépendantes sur EF, vous pouvez plus tard passer à un autre cadre de persistance. Combien de fois avez-vous vu une telle chose dans le monde réel? Cette raison rend le travail avec EF beaucoup plus difficile car votre référentiel doit exposer de nombreuses fonctionnalités supplémentaires enveloppant ce que EF autorise par défaut.
Dans le même temps, l'encapsulation du code EF peut garder votre code mieux organisé et suivre la règle de séparation des préoccupations. Pour moi, cela peut être le seul réel avantage du référentiel et de l'unité de travail, mais vous devez comprendre que suivre cette règle avec EF rendra peut-être votre code mieux maintenable et mieux lisible, mais dans l'effort initial pour créer votre application sera beaucoup plus élevé et pour les petites applications, cela peut être une complexité inutile.
La deuxième raison est partiellement correcte. Le gros inconvénient d'EF est une architecture rigide qui peut difficilement être moquée.Par conséquent, si vous souhaitez effectuer un test unitaire sur la couche supérieure, vous devez en quelque sorte envelopper EF pour permettre de se moquer de son implémentation. Mais cela a de nombreuses autres conséquences que j'ai décrites ici .
Je suis le blog d'Ayende . Si vous avez déjà utilisé NHibernate, vous connaissez probablement ses articles. Ce type a récemment écrit plusieurs articles contre l'utilisation du référentiel avec NHibernate, mais NHibernate est beaucoup mieux mockable.
la source
IDbSetvous moquer de vous pouvez également définir une interface personnalisée dans votre contexte dérivé, mais c'est tout. Une fois que votre code utilise ChangeTracker, Entries ou quoi que ce soit d'autre, il faudra beaucoup d'efforts pour les envelopper tous.IQueryableou accepteExpression<>comme paramètre qui est mis en interne dans la requête Linq-to-entity, vous définissez une logique en dehors du composant simulé avec des effets secondaires qui ne peuvent pas être testés avec des tests unitaires.Je suis aux prises avec les mêmes problèmes, et la mockability pour les tests unitaires des couches EF est importante. Mais j'ai parcouru cet excellent article qui explique comment configurer EF 4.1 DbContext pour qu'il soit mockable en m'assurant que votre DbContext dérivé implémentait une interface générique et expose IDbSet plutôt que DbSet. Puisque j'utilise une approche Database First, parce que notre base de données existe déjà, j'ai simplement modifié les modèles T4 utilisés pour générer mon DbContext dérivé pour le générer pour renvoyer les interfaces IDbSet, ainsi que pour dériver de mon interface générique. De cette façon, tout peut être facilement moqué et vous n'avez pas besoin d'implémenter votre propre modèle d'unité de travail ou de référentiel. Écrivez simplement votre code de service pour consommer votre interface générique, et lorsque vous passez au test unitaire,
http://refactorthis.wordpress.com/2011/05/31/mock-faking-dbcontext-in-entity-framework-4-1-with-a-generic-repository/
la source
L'une des raisons de la création du référentiel est que vous pouvez masquer l'implémentation de DBSet et DbContext si vous décidez de passer d'EntityFramework à autre chose ou vice versa.
Par exemple, j'utilisais NHibernate et j'ai encapsulé tous les appels à ce framework dans mes classes de référentiel. Ils renvoient IEnumerable pour qu'ils soient "génériques" et mes référentiels ont les opérations CRUD standard (mise à jour, suppression, etc.). Je suis depuis longtemps passé à Entity Framework. Ce faisant, je n'ai pas eu besoin de changer quoi que ce soit dans mes classes ViewModel ou au-delà, car elles pointaient vers mon référentiel - je n'avais besoin que de modifier l'intérieur de mon référentiel. Cela a rendu la vie beaucoup plus facile lors de la migration.
(J'ai utilisé NHibernate parce que nous nous connectons à l'ISeries, et à l'époque, il n'y avait aucune implémentation économique utilisant EF avec l'ISeries. La seule disponible était de payer 12 000 $ à IBM pour leur DB2Connect)
la source