真实世界的 ASP.NET MVC 存储库

Question

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

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

那么：

1. 我应该为每个表使用一个存储库吗？

2. 我想这就是聚合概念发挥作用的地方？我应该为每个聚合拥有一个存储库吗？

3. 我是否只需向控制器的构造函数添加所需数量的存储库？

4. 这是我的设计错误的迹象吗？

注意：

IMmember 接口本质上代表一个帮助器对象，它为会员提供者提供了一个漂亮的面孔。即，它将所有代码放在一处。例如：

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

其中一个问题肯定是缓存这种输出。我能感觉到另一个问题正在出现。

编辑：

我使用 Ninject 进行 DI，并且对整个 DI、DDD 和 TDD 很感兴趣。嗯，有点像。我也努力成为一个实用主义者......

Answer 1

1. 我应该为每个表使用一个存储库吗？

可能不会。如果每个表都有一个存储库，那么您实际上是在执行 Active Record。我个人也更喜欢避免将这些类称为“存储库”，因为域驱动设计的“存储库”概念和每表类“存储库”之间可能会发生混淆，后者似乎已普遍用于 Linq2SQL、SubSonic等等以及很多MVC教程。

2. 我想这就是聚合概念发挥作用的地方？我应该为每个聚合拥有一个存储库吗？

是的，是的。如果你要走这条路。

'3。'我是否只需将所需数量的存储库添加到控制器的构造函数中？

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

相反，我的控制器具有负责返回视图模型的查询类。查询类引用编译视图模型所需的任何存储库（或其他数据源）。

Answer 2

好吧@awrigley，这是我的建议：

问：我应该为每个表使用一个存储库吗？

答：不，正如您在问题 2 中提到的。每个聚合使用一个存储库，并仅在聚合根上执行操作。

问：我是否可以将所需数量的存储库添加到控制器的构造函数中？

答：我猜你正在使用 IoC 和构造函数注入，好吧，在这种情况下，请确保你只传递真正的依赖项。 这篇文章可能会帮助您决定这个主题。

（pst！那个空捕获不是一件好事！！）；）

干杯！

Answer 3

这一切都取决于您将如何实现“领域驱动设计”。你知道什么是聚合根吗？大多数时候，一个可以完成所有基本 CRUD 操作的通用类型存储库就足够了。只有当您开始拥有具有上下文和边界的厚模型时，这一点才开始变得重要。