【转】EntityFramework之领域驱动设计实践（九）

原文地址：http://www.cnblogs.com/daxnet/archive/2010/07/10/1774706.html

仓储的实现：深入篇 早在年前的时候就已经在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();

}

始终坚持一个原则：不要在生成的代码上直接修改，一是工作量巨大，另一方面就是，代码是自动生成的，今后模型修改了，代码将会重新生成。