架构问题:Fluent NHibernate,Repository模式和ASP.NET MVC

Question

我刚刚开始了一个新项目,并且自然而然地选择使用了许多新技术.

我正在使用(流畅的)NHibernate,ASP.NET MVC 3,我正在尝试应用Repository模式.

我决定将我的业务逻辑分离成一个单独的项目,并定义包装我的存储库的服务,这样我就可以返回POCO而不是NHibernate代理,并在我的前端和DA逻辑之间保持更多的分离.这也将使我能够轻松提供与API相同的逻辑(一项要求).

我选择使用通用IRepository<T>接口,其中T一个是我的NHibernate映射实体,它们都实现了IEntity(我的界面只是一个标记).

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

如果我改变了另一个悬挂的物体

• Root < - 已更改
  • 孩子< - 改变了

在我的服务中,我必须做以下事情:

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. 的相反情况不成立。聚合中的子记录可以具有其他根记录的外键。