3

虽然我没有做完整的 DDD，但我发现存储库模式很有吸引力，并且我确实尝试沿聚合根边界对存储库进行分段。我在实体框架之上实现存储库，这里 ObjectContext 允许工作单元样式，因为它跟踪实体的更改，并在调用 SaveChanges 时生成适当的 SQL。

我在我的存储库中使用两种不同的方法来解决何时调用 SaveChanges 的问题——区别似乎在于我是采用工作单元还是活动记录语义。如果我将存储库接口定义为如下所示：

public interface IRepository<T>
{
    T Get(int id);
    IList<T> GetAll();
    IQueryable<T> Query();
    void Delete(T entity);
    void Add(T entity);
    IUnitOfWork GetUnitOfWork();
}

和 IUnitOfWork 是

public interface IUnitOfWork
{
    void SaveChanges();
}

然后在 Add(T entity) 实现中，我似乎有两个选择：

    public void Add(Document entity)
    {
        DB.AddToDocumentSet(entity);
        GetUnitOfWork().SaveChanges();  //delegates to the ObjectContext's SaveChanges
    }

或者

    public void Add(Document entity)
    {
        DB.AddToDocumentSet(entity);
    }

在前一种情况下，存储库的 Add 方法在每个操作上发送 SQL。在后一种情况下，调用代码负责从存储库中获取工作单元，并在认为合适时调用 SaveChanges。这允许工作单元跨越不同的存储库（我确保每个存储库在其构建中获得相同的工作单元）。

我的直觉是第二种方法更灵活。采用工作单元模式还意味着对实体的更新会更好一些，因为调用代码只需更新存储库返回的实体的属性，然后调用 UnitOfWork.SaveChanges。

在使用存储库模式时，一种方法通常优于另一种方法吗？

4

1 回答 1

2

这取决于您没有说明的故障模式要求。这主要是关于如何处理工作单元期间发生的故障的问题。您基本上有两种选择，尽管可能还有其他更复杂的变体：

  1. 保存工作单元期间发生的所有更改，直到失败。
  2. 回滚由于故障而在工作单元期间发生的所有更改。

您的第一个 Add 方法更适合方案 1，您的第二个 Add 方法更适合方案 2。

场景 1 可能需要智能应用程序代码以允许用户在故障点恢复。场景 2 更容易在应用程序端实现，但如果他们在失败时将 8 步变成 9 步流程，则可能会让用户感到沮丧。

于 2009-10-16T08:55:48.063 回答