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

【问题标题】：Real World ASP.NET MVC Repositories真实世界的 ASP.NET MVC 存储库
【发布时间】：2010-11-24 17:18:50
【问题描述】：

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

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

所以：

我应该为每个表使用一个存储库吗？
我想这就是聚合概念发挥作用的地方？每个聚合是否应该有一个存储库？
我是否只需将所需数量的存储库添加到控制器的构造函数中？
这是否表明我的设计有误？

注意：

IMember 接口本质上表示一个帮助器对象，它为成员资格提供者提供了一个漂亮的面孔。即，它将所有代码放在一个地方。例如：

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

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

编辑：

我将 Ninject 用于 DI，并且在整个 DI、DDD 和 TDD 方面都非常畅销。嗯，有点。我也努力做一个实用主义者……

【问题讨论】：

Repository pattern: One repository class for each entity? 的可能重复项 - 每个月左右都会弹出。
@jfar - 所以你投票关闭某个重复的东西，然后你在这里发布你在那个重复的问题（逐字）中得到的完全相同的答案？它是如何工作的？？
@RPM1984 - 因为骗子很少再关闭，我不希望 qstarins 回答是这个问题中唯一的一个。

标签： asp.net-mvc repository-pattern repository ddd-repositories multiple-repositories

【解决方案1】：

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

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

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

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

'3.'我是否只需向 Controller 的构造函数中添加所需数量的存储库？

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

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

【讨论】：

#1 的问题。与直接针对 datacontext/nhib-session 相比，存储库将您的 ORM 抽象出来并提供更可测试的接口。这些类并非毫无意义，并且可以包含特定于持久性的逻辑，例如更新“上次更新”。
@qstarin 我有一个类似的设置，只是我们通过域服务访问存储库。
@jfar：“无意义”有点强。但这些问题并不需要专门的“存储库”，我发现值得避免与 DDD 的“存储库”概念的潜在混淆。如果它们是每表数据访问对象，我倾向于称它们为 DAO。此外，如果您正在为每个表做存储库，那么您并没有真正使用 ORM。好吧，从技术上讲，您可能正在使用 ORM，但没有使用 M 部分。
@qstarin - 存储库与 DDD 无关。它是一种可以独立存在的模式。你对 ORM 部分完全错误。那仍然是映射和加载嵌套/相关实体仍然是 ORM 的重要组成部分。我认为您试图描绘“除非您使用 DDD，否则您是原始人”的糟糕画面。
@qstarin 得到了饼干，因为他的答案指向了正确的方向。它阐明了为什么服务层是一个好主意。

【解决方案2】：

@awrigley，这是我的建议：

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

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

问：我是否只需在 Controller 的构造函数中添加所需数量的存储库？

A：我猜你正在使用 IoC 和构造函数注入，好吧，在这种情况下，请确保你只传递真正的依赖项。 this post 可以帮助你决定这个话题。

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

干杯！

【讨论】：

empty catch = 仍在开发中并且 = 未来的错误！

【解决方案3】：

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

【讨论】：