架构问题：Fluent NHibernate、存储库模式和 ASP.NET MVC

Question

我刚刚开始一个新项目，自然选择使用很多新技术。

我正在使用（流畅的）NHibernate、ASP.NET MVC 3，并尝试应用存储库模式。

我决定将我的业务逻辑分离到一个单独的项目中，并定义包装我的存储库的服务，以便我可以返回 POCO 而不是 NHibernate 代理，并在我的前端和 DA 逻辑之间保持更多的分离。这也让我能够轻松地提供与 API 相同的逻辑（一项要求）。

我选择使用通用的 IRepository 接口，其中 T 是我的 NHibernate 映射实体之一，它们都实现 IEntity（我的接口实际上只是一个标记）。

问题是这违背了聚合根模式，我开始感受到贫血域模型的痛苦。

如果我更改挂在另一个根上的对象

• <- 已更改
  • 子项<-已更改

在我的服务中，我必须执行以下操作：

public void AddNewChild(ChildDto child, rootId)
{
    var childEntity = Mapper.Map<ChildDto,ChildEntity>(child);
    var rootEntity = _rootrepository.FindById(rootId);
    rootEntity.Children.Add(childEntity);
    _childRepository.SaveOrUpdate(child);
    _rootRepository.SaveOrUpdate(root);
}

如果我不先保存孩子，我会从 NHibernate 获得异常。我觉得我的通用存储库（我目前在一项服务中需要 5 个）不是正确的方法。

 public Service(IRepository<ThingEntity> thingRepo, IRepository<RootEntity> rootRepo, IRepository<ChildEntity> childRepo, IRepository<CategoryEntity> catRepo, IRepository<ProductEntity> productRepo)

我觉得这不是让我的代码变得更灵活，而是让它变得更脆弱。如果我添加一个新表，我需要在所有测试中更改构造函数（我使用 DI 来实现，所以这还不错），但它看起来有点臭。

有人对如何重组这种架构有什么建议吗？

我应该让我的存储库更加具体吗？服务抽象层是否迈得太远了？

编辑：有一些很好的相关问题很有帮助：

• 存储库模式最佳实践
• 存储库模式帮助
• 建筑难题

Answer 1

当您拥有聚合时，聚合父级（根）及其子级的存储库是相同的，因为子级的生命周期由根对象控制。

根对象类型的“保存”方法还应该直接负责保存对子记录的更改，而不是将其委托到另一个存储库中。

此外，在“正确的”聚合模式中，子记录没有自己的标识（至少有一个在聚合外部可见）。这有几个直接后果：

1. 外部记录/聚合中不能有外键到这些子记录。
2. 从第 1 点开始，每次保存根对象状态时，您都可以删除并重新创建数据库中的子记录。如果您遇到优先级问题，这通常会使您的持久性逻辑变得更容易。

注意：1. 的相反情况不成立。聚合中的子记录可以具有其他根记录的外键。

Answer 2

我觉得这不但没有让我的代码变得更灵活，反而让它变得更脆弱。如果我添加一个新表，我需要在所有测试中更改构造函数（我使用 DI 来实现，所以这还不算太糟糕），但它看起来有点臭。

实现工作单元模式在你的存储库中。这实际上意味着您有一个工作单元类，它通过 ctor 或属性注入来保存您的服务注入。此外，它还拥有提交和/或事务方法。仅在您的服务中注入 IUnitOfWork 实例。添加存储库时，您只需更改工作单元，而不需要触及业务逻辑（服务）。