虽然我没有做完整的 DDD,但我发现存储库模式很吸引人,而且我确实尝试沿聚合根边界对存储库进行分段。我在 Entity Framework 之上实现存储库,这里 ObjectContext 允许使用工作单元样式,因为它跟踪对实体的更改,并在调用 SaveChanges 时生成适当的 SQL。
关于何时调用 SaveChanges,我在我的存储库中纠结于两种不同的方法——区别似乎在于我是采用工作单元语义还是采用事件记录语义。如果我将存储库接口(interface)定义为如下所示:
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。
在使用存储库模式时,一种方法是否普遍优于另一种方法?
最佳答案
这取决于您没有说明的故障模式要求。这主要是关于如何处理在您的工作单元中发生的故障的问题。您基本上有两种选择,尽管还有其他可能的更复杂的变体:
- 保存工作单元期间发生的所有更改,直到失败。
- 回滚由于失败而在工作单元期间发生的所有更改。
您的第一个 Add 方法更适合场景 1,您的第二个 Add 方法更适合场景 2。
场景 1 可能需要智能应用程序代码以允许用户在故障点恢复。方案 2 在应用程序端更容易实现,但如果用户在 9 步流程中执行 8 步失败时可能会感到沮丧。
关于entity-framework - Repository 模式与 Unit of Work 或 ActiveRecord 的一致性如何,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1572755/