Référentiels ASP.NET MVC du monde réel

Question

Dans le monde réel, les contrôleurs peuvent potentiellement avoir besoin d'utiliser des données provenant de diverses tables de base de données et d'autres magasins de données. Par exemple :

[Authorize]
    public class MembersController : Controller
    {
        ICourseRepository repCourse;
        IUserCourseRepository repUserCourse;
        IMember member;
        public MembersController(ICourseRepository repCourse, IUserCourseRepository repUserCourse, IMember member)
        {
            this.repCourse = repCourse;
            this.repUserCourse = repUserCourse;
            this.member = member;
        }

Donc :

1. Dois-je utiliser un référentiel pour chaque table ?

2. Je suppose que c'est là que le concept d'agrégats entre en jeu ? Devrais-je avoir un référentiel par agrégat ?

3. Dois-je simplement ajouter autant de dépôts que nécessaire au constructeur du contrôleur ?

4. Est-ce un signe que ma conception est mauvaise ?

NOTE :

L'interface IMember représente essentiellement un objet d'aide qui donne un visage agréable au fournisseur d'adhésion. En d'autres termes, elle regroupe tout le code en un seul endroit. Par exemple :

        Guid userId;
        public Guid UserId
        {
            get
            {
                if (userId == null)
                {
                    try
                    {
                        userId = (Guid) Membership.GetUser().ProviderUserKey;
                    }
                    catch { }
                }
                return userId;
            }
        }

Le problème qui se pose est certainement la mise en cache de ce type de résultats. Je sens qu'une autre question arrive.

EDIT :

J'utilise Ninject pour le DI et je suis assez convaincu par tout ce qui est DI, DDD et TDD. Enfin, en quelque sorte. J'essaie aussi d'être un pragmatique...

Answer 1

1. Dois-je utiliser un référentiel pour chaque table ?

Probablement pas. Si vous avez un référentiel par table, vous faites essentiellement du Active Record. Personnellement, je préfère aussi éviter d'appeler ces classes "Repository" à cause de la confusion qui peut se produire entre le concept de "Repository" de Domain Driven Design et la classe par table "Repository" qui semble être devenue couramment utilisée avec Linq2SQL, SubSonic, etc. et de nombreux tutoriels MVC.

2. Je suppose que c'est là que le concept d'agrégats entre en jeu ? Devrais-je avoir un référentiel par agrégat ?

Oui et oui. Si vous choisissez cette voie.

'3.' Dois-je ajouter autant de référentiels que nécessaire au constructeur du contrôleur ?

Je ne laisse pas mes contrôleurs toucher directement mes dépôts. Et je ne laisse pas non plus mes Views toucher directement mes classes de domaine.

Au lieu de cela, mes contrôleurs ont des classes de requête qui sont responsables du retour des modèles de vue. Les classes d'interrogation font référence aux référentiels (ou autres sources de données) dont elles ont besoin pour compiler le modèle de vue.

Answer 2

Eh bien @awrigley, voici mon conseil :

Q : Dois-je utiliser un référentiel pour chaque table ?

R : Non, comme vous l'avez mentionné à la question 2, utilisez un référentiel par agrégat et effectuez les opérations sur l'agrégat Root uniquement.

Q : Est-ce que je dois ajouter autant de Dépôts que nécessaire au constructeur du Contrôleur ?

R : Je suppose que vous utilisez IoC et l'injection de constructeur. Dans ce cas, assurez-vous de ne transmettre que les dépendances réelles. ce poste peut vous aider à prendre une décision sur ce sujet.

(pst ! cette prise vide n'est pas une belle chose !!) ;)

A la vôtre !

Answer 3

Tout dépend de la manière dont vous allez concevoir le "Domain Driven Design". Savez-vous ce qu'est une racine agrégée ? La plupart du temps, un référentiel typographié génériquement qui peut faire tous vos CRUD de base sera suffisant. Ce n'est que lorsque vous commencez à avoir des modèles épais avec un contexte et des limites que cela commence à avoir de l'importance.