最近开发的MVC项目使用了Repository模式。
啥是Repository模式？
从图看，有一个仓库接口，一个实现了这个仓库接口的基类；然后在使用方，一方面，要声明一个继承于仓库接口的子接口，另一方面，编写一个数据库操作类，继承仓库基类，并实现这个子接口。
继承仓库基类容易理解，为啥还要搞一个子接口呢？直接实现仓库接口不就完啦？思考其中原因，应该是为了控制反转，依赖注入，总之一个类对应一个接口就是了。
Repository模式意义何在呢？
Repository模式是一个中间层，位于 数据库映射层 和 领域层（业务逻辑层）之间。本来嘛，ORM或者DAL已经为我们隔离了数据库，BLL并没有直接访问数据库，如果数据库更换，那改写ORM或DAL即可。那么现在又增加一层Repository，目的何在呢?
摘录一些话，姑妄听之。反正他们牛逼，怎么说都行：
Repository 是一个独立的层，介于领域层与数据映射层 (数据访问层) 之间。它的存在让领域层感觉不到数据访问层的存在，它提供一个类似集合的接口提供给领域层进行领域对象的访问。Repository 是仓库管理员，领域层需要什么东西只需告诉仓库管理员，由仓库管理员把东西拿给它，并不需要知道东西实际放在哪。(咦，难道DALORM不是这样的吗？)
Repository 模式是架构模式，在设计架构时，才有参考价值；
Repository 模式主要是封装数据查询和存储逻辑；
Repository 模式实际用途：更换、升级 ORM 引擎，不影响业务逻辑；
Repository 模式能提高测试效率，单元测试时，用 Mock 对象代替实际的数据库存取，可以成倍地提高测试用例运行速度。
这几句话中，好像亮点在于换ORM，比如将NHibernate换成EF，BLL也不受影响。呵呵。
也有一些钻研者自我安慰：
使用Repository，隐含着一种意图倾向，就是 Domain需要什么我才提供什么，不该提供的功能就不要提供，一切都是以Domain的需求为核心；而使用Dal，其意图倾向在于我Dal层能使用的数 据库访问操作提供给Business层，你Business要用哪个自己选。换一个Business也可以用我这个Dal，一切是以我Dal能提供什么操 作为核心。
也有后起之秀顿悟：
仓储模式最大的优点就是所有的数据访问首先是通过仓库的，对仓库的增删改都不会立即提交到数据库，而只有当调用了仓库包裹器，这些增删改的操作才会一次提交到数据库。
但我怎么看，都看不出这个批量提交、仓库包裹器与Repository有什么关系。
今天看到一种隐隐约约的说法，说资源库（大概就是Repository模式吧）有个好处，就是可以兼容缓存。BLL通过资源库来存取数据，而不必知道这些数据是来自于数据库还是缓存。