使用 ORM 时的命令/查询分离答案

【问题标题】：Command/Query separation when using an ORM使用 ORM 时的命令/查询分离
【发布时间】：2012-06-01 11:50:16
【问题描述】：

在我的各种项目中，我实现了命令/查询分离模式并使用 NHibernate 作为我的 ORM。

一般而言，我将命令和查询保存在与特定活动集相关的单独项目中，例如UserManagement、TagManagement、QuestionManagement 等。

我非常喜欢将所有内容都很好地划分到这些存储库中，这些存储库具有易于查找的功能。这样做当然有好处。

然而，我开始怀疑这种抽象对于基本查询的价值，尤其是考虑到 NHibernate 本身已经提供了如此强大的抽象。

在我的 MVC 控制器中考虑这个：

_nHibernateSession.Get<UserProfile>(_sessionData.UserId);

我可以将其抽象为 UserManagement 存储库中的查询，但我不确定它提供了什么价值。

你怎么看？您会将所有内容都保留在命令/查询范式中，还是直接在控制器中使用 nhibernate 会话来处理此类简单请求？

【问题讨论】：

标签： c# asp.net-mvc nhibernate command-query-separation

【解决方案1】：

通常我不使用存储库，因为我认为它们在我的代码中添加了太多抽象。我更喜欢直接在服务/控制器层构建的视图模型。如果我想编写一个单元测试，我可以针对服务或控制器编写它。如果你想重用一些查询条件，那么只需编写扩展方法：

    public static IQueryable<User> Administrators(this IQueryable<User> users)
    {
        return users.Where(x => x.Role.Id == Role.Const.Admin);
    }

【讨论】：

【解决方案2】：

我更喜欢将所有查询保留在存储库中，如果您需要进行很多不同的查询，您可以公开实现 IQueryable 并包装 session.Query 的 LINQ To Nhibernate 的存储库，对 HQL 或标准有限制。

但对我来说，这样做没有正当理由，只有当您向其他人提供 数据访问层并且您不知道查询时。

您可以在我正在工作的 DDD project 上看到一个示例。

【讨论】：

【解决方案3】：

我强烈建议您在 MVC 控制器和 NHibernate 之间保持一定程度的抽象，尤其是在您需要对 MVC 控制器进行单元测试时。如果没有存储库层，则创建需要模拟存储库层的单元测试要困难得多。

【讨论】：