EntityFramework之领域驱动设计实践（九）：储的实现：深入篇

早在年前的时候就已经在CSAI博客发表了上一篇文章：《仓储的实现：基础篇》。苦于日夜奔波于工作与生活之间，一直没有能够抽空继续探讨仓储的实现细节，也让很多关注EntityFramework和领域驱动设计的朋友们备感失望。

闲话不多说，现在继续考虑，如何让仓储的操作在相同的事物处理上下文中进行。DDD引入仓储模式，其目的之一就是能够通过仓储隐藏对象持久化的技术细节，使得领域模型变得更为“纯净”。由此可见，仓储的实现是需要基础结构层的组件支持的，表现为对数据库的操作。在传统的关系型数据库操作中，事务处理是一个很重要的概念，虽然从目前某些大型项目看，事务处理会降低效率，但它保证了数据的完整性。关系型数据库仍然是目前数据持久化机制的主流，事务处理的实现还是很有必要的。

为了迎合仓储模式，就需要对经典的ObjectContext使用方式作一些调整。比如，原本我们可以非常简单地使用using (EntitiesContainer ec = new EntitiesContainer())语句来界定LINQ to Entities的操作范围，并使用ObjectContext的SaveChanges成员方法提交事务，而在引入了仓储的实现中，就不能继续采用这种经典的使用方式。这让EntityFramework看上去变得很奇怪，也很牵强，我相信很多网友会批评我的做法，因为我把问题复杂化了。

其实，这应该是关注点不同罢了。关注EntityFramework的开发人员，自然觉得经典的调用方式简单明了，而从DDD的角度看呢？只能把关注点放在仓储上，而把EntityFramework当成是仓储的一种技术选型（当然从DDD角度讲，我们完全可以不选择 EntityFramework，而去选择其它技术）。所以本文暂且抛开EntityFramework，继续在上文的基础上，讨论仓储的实现。

前面提到，仓储的实现需要考虑事务处理，而且根据DDD的经验，针对每一个聚合根，都需要有个仓储对其进行持久化以及对象重新组装等操作。为此，我的想法是，将仓储操作“界定”在某一个事务处理上下文（Context）中，仓储的实例是由Context获得的，这有点像 EntityFramework中ObjectContext与EntityObject的关系那样。由于仓储是来自于transaction context，所以它知道目前处于哪个事务上下文中。我定义的这个transaction context如下：

Transaction Context

public　interface　IRepositoryTransactionContext　:　IDisposable
{
　　 IRepository<TEntity>　GetRepository<TEntity>()
　　　　 where　TEntity　:　EntityObject,　IAggregateRoot;
　　 void　BeginTransaction();
　　 void　Commit();
　　 void　Rollback();
}


上面第三行代码定义了一个接口方法，这个方法的主要作用就是返回一个针对指定聚合根实体的仓储实例。剩下那三行代码就很明显了，那是标准的 transaction操作：启动事务、提交事务以及回滚事务。