asp.net-mvc – 真实世界的ASP.NET MVC存储库

在现实世界中,控制器可能需要使用来自各种数据库表和其他数据存储的数据.例如：

[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;
        }

所以：

>我应该为每个表使用存储库吗？
>我想这是agregates的概念发挥作用的地方？我应该每个聚合有一个存储库吗？
>我是否只需要向Controller的构造函数添加所需数量的存储库？
>这是否表明我的设计有误？

注意：

IMember接口本质上代表一个帮助对象,它在成员资格提供程序上放置了一个很好的面孔.即,它将所有代码放在一个地方.例如：

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

这方面的一个问题肯定是缓存这种输出.我可以感受到另一个问题.

编辑：

我正在使用Ninject进行DI,并且在整个DI,DDD和TDD上都很畅销.好吧,有点.我也试图成为一个实用主义者……

解决方法

1. Should I use a repository for each table?

可能不是.如果每个表都有一个存储库,那么基本上就是在进行Active Record.我个人也更愿意避免将这些类称为“存储库”,因为域驱动设计的“存储库”概念与类似于每个表的“存储库”之间可能出现的混淆似乎已经成为Linq2sql,SubSonic的常用例子等等和许多MVC教程.

2. I guess this is where the concept of agregates comes into play? Should I have one Repository per aggregate?

是的,是的.如果你打算走这条路.

‘3.’ Do I just add as many Repositories as I need to the constructor of the Controller?

我不让我的控制器直接触摸我的存储库.而且我也不让我的视图直接触及我的域类.

相反,我的控制器有Query类,负责返回View Models. Query类引用编译View Model所需的任何存储库(或其他数据源).