关于Repository 设计模式
2014-08-26 08:41
211 查看
在《企业架构模式》中,译者将Repository翻译为资源库。给出如下说明:
通 过用来访问领域对象的一个类似集合的接口,在领域与数据映射层之间进行协调。
在《领域驱动设计:软件核心复杂性应对之 道》中,译者将Repository翻译为仓储,给出如下说明:
一种用来封装存储,读取和查找行为的机制,它模拟了一个对象集 合。
使用该模式的最大好处就是将领域模型从客户代码和数据映射层之间解耦出来。
定义(来自Martin Fowler的《企业应用架构模式》):
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
个人理解:Repository是一个独立的层,介于领域层与数据映射层(数据访问层)之间。它的存在让领域层感觉不到数据访问层的存在,它提供一个类似集合的接口提供给领域层进行领域对象的访问。Repository是仓库管理员,领域层需要什么东西只需告诉仓库管理员,由仓库管理员把东西拿给它,并不需要知道东西实际放在哪。
tabbycat的理解(来源):
1. Repository模式是架构模式,在设计架构时,才有参考价值;
2. Repository模式主要是封装数据查询和存储逻辑;
3. Repository模式实际用途:更换、升级ORM引擎,不影响业务逻辑;
4. Repository模式能提高测试效率,单元测试时,用Mock对象代替实际的数据库存取,可以成倍地提高测试用例运行速度。
评估:应用Repository模式所带来的好处,远高于实现这个模式所增加的代码。只要项目分层,都应当使用这个模式。
关于泛型Repository接口(来源):
仅使用泛型Repository接口并不太合适,因为Repository接口是提供给Domain层的操作契约,不同的entity对于Domain来说可能有不同的操作约束。因此Repository接口还是应该单独针对每个Eneity类来定义。
泛型的Repository<T>类仍然用来减少重复代码,只是不能被UserRepository类直接继承,因为这样Delete方法将侵入User类,所以改为在UserRepository中 组合一个Repository<T>,将开放给domain可见且又能使用泛型重用的功能委托给这个Repository<T>
Repository与Dal的区别(来源):
Repository是DDD中的概念,强调Repository是受Domain驱动的,Repository中定义的功能要体现Domain的意图和约束,而Dal更纯粹的就是提供数据访问的功能,并不严格受限于Business层。
使用Repository,隐含着一种意图倾向,就是 Domain需要什么我才提供什么,不该提供的功能就不要提供,一切都是以Domain的需求为核心;而使用Dal,其意图倾向在于我Dal层能使用的数 据库访问操作提供给Business层,你Business要用哪个自己选。换一个Business也可以用我这个Dal,一切是以我Dal能提供什么操 作为核心。
通 过用来访问领域对象的一个类似集合的接口,在领域与数据映射层之间进行协调。
在《领域驱动设计:软件核心复杂性应对之 道》中,译者将Repository翻译为仓储,给出如下说明:
一种用来封装存储,读取和查找行为的机制,它模拟了一个对象集 合。
使用该模式的最大好处就是将领域模型从客户代码和数据映射层之间解耦出来。
定义(来自Martin Fowler的《企业应用架构模式》):
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
个人理解:Repository是一个独立的层,介于领域层与数据映射层(数据访问层)之间。它的存在让领域层感觉不到数据访问层的存在,它提供一个类似集合的接口提供给领域层进行领域对象的访问。Repository是仓库管理员,领域层需要什么东西只需告诉仓库管理员,由仓库管理员把东西拿给它,并不需要知道东西实际放在哪。
tabbycat的理解(来源):
1. Repository模式是架构模式,在设计架构时,才有参考价值;
2. Repository模式主要是封装数据查询和存储逻辑;
3. Repository模式实际用途:更换、升级ORM引擎,不影响业务逻辑;
4. Repository模式能提高测试效率,单元测试时,用Mock对象代替实际的数据库存取,可以成倍地提高测试用例运行速度。
评估:应用Repository模式所带来的好处,远高于实现这个模式所增加的代码。只要项目分层,都应当使用这个模式。
关于泛型Repository接口(来源):
仅使用泛型Repository接口并不太合适,因为Repository接口是提供给Domain层的操作契约,不同的entity对于Domain来说可能有不同的操作约束。因此Repository接口还是应该单独针对每个Eneity类来定义。
泛型的Repository<T>类仍然用来减少重复代码,只是不能被UserRepository类直接继承,因为这样Delete方法将侵入User类,所以改为在UserRepository中 组合一个Repository<T>,将开放给domain可见且又能使用泛型重用的功能委托给这个Repository<T>
Repository与Dal的区别(来源):
Repository是DDD中的概念,强调Repository是受Domain驱动的,Repository中定义的功能要体现Domain的意图和约束,而Dal更纯粹的就是提供数据访问的功能,并不严格受限于Business层。
使用Repository,隐含着一种意图倾向,就是 Domain需要什么我才提供什么,不该提供的功能就不要提供,一切都是以Domain的需求为核心;而使用Dal,其意图倾向在于我Dal层能使用的数 据库访问操作提供给Business层,你Business要用哪个自己选。换一个Business也可以用我这个Dal,一切是以我Dal能提供什么操 作为核心。
相关文章推荐
- 关于23种设计模式的有趣见解
- 关于选择页面的设计模式
- 关于23种设计模式得有趣见解
- ::关于设计模式(Design Patterns)::
- 关于23种设计模式的有趣见解(转)
- 关于Singleton设计模式的计数器代码实例(拷贝粘贴即可学习)
- 关于 设计模式 的精彩文章
- 关于系统设计和模式的两篇不错的文章
- 推荐一本关于设计模式的好书
- 关于Gof设计模式的精辟总结
- [转载]关于23种设计模式的有趣见解
- 关于23种设计模式的有趣见解(转)
- 关于23种设计模式的有趣见解(转)
- (转)关于23种设计模式的有趣见解
- [转载]关于23种设计模式的有趣见解
- 关于23种设计模式的有趣见解(转)
- 关于23种设计模式的有趣见解(转)
- 关于23种设计模式
- (转)关于23种设计模式的有趣见解
- 关于设计模式的思考(k_eckel转自微软高校博客K_eckel's mindview)