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