数据访问层：飞鸽传书很多人对数据访问层的职责的理解相对狭隘，认为我们的数据访问层只要飞鸽传书帮助我们实现增删改查（CRUD）即可，其实数据访问层远非我们想象中那么简单。CRUD是他必须提供的功能，除此之外它还必须帮助业务逻辑层，屏蔽掉具体的数据访问技术的差异，这就要求它提供统一的数据访问接口，如果您读过我前面的三篇文章，相信您对这一方面就不会陌生了。我认为一个优秀的数据访问层，还应该支持工作单元模式，仓储模式，并能够有效的控制并发带来的各种问题，如果您能够不借助ORM框架做到这一点，那么恭喜您，您会是一个很好的微软专家的。就我前面的三篇来说，如果我采用ADO.NET去实现数据访问层，很显然，这将是一个浩大的工程，这就基本上要求我重新写一个类似微软EF的框架了，很显然我不具备这样的实力。下面跟大家着重的说一说工作单元模式，与仓储模式。
工作单元模式：其实在EF里面已经为我们实现了，当我们做增删改查的时候，我们并不是每次都向数据库提交请求，而是把相应的更改状态记录在内存里面，然后点击提交的时候一次向数据库写入，这样做有什么好处呢？很显然，第一降低了数据库访问次数，提升了性能，第二，所有的操作一次性提交，这样能很好的支持事务操作。工作单元模式说出来很简单，借助EF框架也容易实现。但是试想一下，如果让您亲手去实现这个模式，又该怎么去折腾呢？
仓储模式：其实这个模式我们经常用到，只是我们没有注意到罢了。比如我们会为数据库每一张表去建立一个数据实体以及操作这个实体的一个专门的数据库访问类，很显然这个数据库访问类就是一个仓存，如我前面几篇文章中的数据访问层中的orderDAL类，但是仓储真这么简单么? 在前面我提到了我们的业务逻辑层将采用领域模型来组织业务。既然是领域模型，那肯定是一个一个抽象的业务对象啦，业务对象里面肯定包含数据与行为。例如订单对应的领域模型中，肯定会包含该订单的所有订单明细实体，他的行为中肯定是包含了对订单明细项的CRUD，那么这个时候，我们的仓储类要解决就是针对我们的订单领域模型的CRUD，很显然这是一个多表操作。我们在仓储中不仅要实现对订单表的CRUD，还要帮助其实现模型中对订单明细的CRUD，或许你认为这个很容易，那么想一想我们如果订单表中还有客户呢？很显然，要实现面向对象的领域模型的数据仓储，并非想象中那么容易，好在EF也提供了相应的支持，如果要自己去写一个ADO.net针对领域模型的仓储，其痛苦可想而知......