Je souhaite utiliser Layered Architecture et EF, Repository et UoW Pattern dans le projet.Quelle couche doit être DBContext, Repository et UnitOfWork?
Quelle couche doit être DBContext, Repository et UnitOfWork?
DAL ou BLL? DAL est l'acronyme de Data Access Layer (couche d'accès aux données).
Je mettrais votre implémentation DbContext dans votre couche DAL (Data Access Layer). Vous aurez probablement des opinions différentes à ce sujet, mais je ne mettrais pas en œuvre les modèles de référentiel ou d'unité de travail. Techniquement, le DBContext est l'unité de travail et le IDbSet est un référentiel. En mettant en œuvre le vôtre, vous ajoutez une abstraction au-dessus d'une abstraction.
DbContext, les référentiels et Unit of Work sont liés à l'utilisation de données, vous devez donc les placer définitivement dans DAL.
"Devrait" n'est probablement pas le mot correct ici, car il y a beaucoup de vues sur ce sujet. Si vous voulez mettre en œuvre ces modèles du livre, je voudrais vérifier ce lien des gars ASP.NET: https://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application
Mais je l'ai effectivement commencé à la couche comme ceci:
Controller/Logic < - Où la logique métier et les objets frontières sont créés et transformés.
dépôt < - Lorsque la logique liée à la persistance et la transformation des entités et des objets requête
magasin < - Lorsque les implémentations actuelles des mécanismes de stockage résident. Ceci est abstrait derrière une interface. De cette manière, le fait que la logique métier et la logique de référentiel soient testables, découplées et libres d'utiliser n'importe quel mécanisme de persistance, ou son absence, est mis à profit de cette manière. Sans le reste de l'application, sachant quoi que ce soit à ce sujet.
Ceci est vrai vrai avec d'autres modèles, c'est juste mon point de vue. DbContext ne devrait jamais dépasser les limites de la DAL, si vous voulez y mettre vos dépôts ou vos unités de travail, vous êtes libre de ne pas les laisser divulguer leurs détails ou leurs dépendances vers le haut. Le DbContext devrait selon moi avoir une portée aussi limitée que possible, pour le garder le plus propre possible - vous ne savez jamais où ce contexte a été ... portez s'il vous plaît une protection! Mais blague à part, si vous avez une application asynchrone, multithread, multinode, grande, en utilisant ces DbContexts partout en les faisant circuler, vous aurez des problèmes généraux de concurrence et de course de données. Ce que j'aime faire est de commencer avec un magasin InMemory, que j'injecte dans mon contrôleur. Dès que ce magasin commence à servir plusieurs entités, et que la logique de persistance devient de plus en plus complexe, je la refactorise dans un magasin avec un référentiel au-dessus. Une fois que tous mes tests sont passés et que je l'ai fait fonctionner comme je le souhaite, je commence à créer une base de données ou des implémentations basées sur le système de fichiers de ce magasin.
Encore une fois mes opinions ici, parce que c'est une question assez générale, qui a peu de "vraies" réponses, juste beaucoup d'opinions.
La plupart des opinions sur ce sont valides, ils ont des forces et des faiblesses différentes, et l'important est de comprendre quelles sont les forces dont vous avez besoin, et comment vous allez travailler avec les faiblesses.
Votre dépôt doit avoir une référence à DbSet<T> objets, et une fois que vous ajoutez, mettre à jour ou de supprimer, d'un ou plusieurs référentiels, vous devez invoquer SaveChanges du UnitOfWork. Par conséquent, vous devez placer DbContext dans l'implémentation de l'unité de travail.
La plupart du temps j'avais une idée. Pourquoi Microsoft ASP.Net propose-t-il de révéler cela? –