文章索引和简介 项目最基础的东西已经结束了，但是现在我们的项目还不健全  不利于测试 重复性代码多   层与层之间耦合性高  不利于扩展等问题.今天的这章 主要就是解决这些问题的。再解决这些问题时，自己也产生了很多疑问，理解的也并不是很透彻 ，希望我的疑问能在这里得到解答~~

这个模式都说烂了，但是为什么几乎都是： public abstract class RepositoryBase : IDisposable { // ... 省略 field 声明 protected RepositoryBase() { this._context = this.CreateContext

近来发现很多ASP.NET MVC的例子中都使用了Repository模式，比如Oxite，ScottGu最近发布的免费的ASP.NET MVC教程都使用了该模式。就简单看了下。 在《企业架构模式》中，译者将Repository翻译为资源库。给出如下说明：通过用来访问领域对象的一个类似集合的接口，在领域与数据映射层之间进行协调。 在《领域驱动设计：软件核心复杂性应对之道》中，译者将Reposito

    本篇博客简单描述了Repository模式在OEA中的应用。 不使用Repository时的问题     OEA框架中使用了DDD的思想，面向领域对象进行开发。在DDD中，有很多重要的概念，例如：聚合实体对象、值对象、仓储、工厂、服务等。（不太了解的Repository和DDD的朋友，可以看Evans写的《Domain Driven Design》。）     在OEA中，实体的实现框架使用了CSLA分布式框架。原来为了简单并保持和CSLA开发模式的兼容，一直都把实体的获取模式直接以静态方法的方式直接写在实体的对应列表类中。例如下面这段代码：     随着应用的慢慢深入，出现了一些问题： 不易支持客户化。OEA是基于产品线的开发，如果采用前面的开发模式，