Loading [MathJax]/jax/input/TeX/config.js
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >2020-5-8-repository模式

2020-5-8-repository模式

作者头像
黄腾霄
发布于 2020-06-10 07:08:59
发布于 2020-06-10 07:08:59
5320
举报
文章被收录于专栏:黄腾霄的博客黄腾霄的博客

今天和大家介绍一下一种特殊的设计模式——仓库模式(repository pattern)


什么是仓库模式(repository pattern)

Martin Flower对此的定义是领域模型层和数据映射层中间的间接层。它封装了一系列数据库对象以及对应的操作。实现了领域模型和数据访问层的解耦。

Repository 模式作用

试想一下,在你的程序中,有多处地方需要查询,修改数据。

你肯定不希望在各个地方重复书写数据访问代码,所以你会将其放置在同一处地方(数据访问层)。

这在大部分场景下都能够满足要求。

但是如果你是使用模型驱动开发的方式进行软件开发,那么就很容易发现这样一个问题——领域模型的格式和数据库的格式不一致。

例如上面的这张图,Buyer和Order是领域模型的两个聚合根,其中Order中包含了OrderItem这一实体对象。

然而在数据层中,Order和OrderItem分别存储在不同的表中。

这就意味着在对Order进行更改时,需要同时更新两张表中的数据。而这个逻辑不应该是领域层应该关心的事情。

Repository 就充当了这一个中间层,封装了从Order这个聚合根到Orders和OrderItems这两张表之间的数据访问业务逻辑。让领域层可以更加关注领域业务逻辑。

其他好处

当然对于Repository 来说,作为一个中间层,也自然会有其他中间层的通用优势。

比如说单元测试时,可以mock数据仓库。面向接口编程,便于替换ORM等数据映射层实现。

Repository 同DAL比较

Repository 模式是模型驱动的,微软在《.NET Microservices: Architecture for Containerized .NET Applications》一书中推荐每一个聚合根都要对应一个Repository 。

Repository 更方便领域模型层对模型数据进行操作。

而DAL是数据驱动的,所有的操作都是面向数据库中的存储方式,进行对应的增删改查。

Repository 也可以在DAL之上进行搭建。

可以说Repository模式的存在就是为了抹平模型表示和数据库存储表示之间的差异。

让数据更容易被领域模型使用。


参考文档:

[Designing the infrastructure persistence layer

Microsoft Docs](https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/infrastructure-persistence-layer-design)

[Repository Pattern

DevIQ](https://deviq.com/repository-pattern/)


本文会经常更新,请阅读原文: https://xinyuehtx.github.io/post/repository%E6%A8%A1%E5%BC%8F.html ,以避免陈旧错误知识的误导,同时有更好的阅读体验。

本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。欢迎转载、使用、重新发布,但务必保留文章署名黄腾霄(包含链接: https://xinyuehtx.github.io ),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。如有任何疑问,请 与我联系

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2020-05-08 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
2020-5-7-规约模式(specification)
假设你正在减肥,不能吃肉,也不能吃卡路里大于500的食物。把这种情况用编程来表示就会是下面这样
黄腾霄
2020/06/10
7270
2020-5-6-restful理解
Restful已经是目前我们耳熟能详的概念了,但是找了下网上的文章,大部分都是介绍restful API范式。很少介绍resetful架构的。今天同大家介绍下对restful的理解。此外,阮一峰的文章也很不错,感兴趣的同学也可以参考。理解RESTful架构 - 阮一峰的网络日志
黄腾霄
2020/06/10
5290
DDD理论学习系列(12)-- 仓储
1. 引言 DDD中Repository这个单词,主要有两种翻译:资源库和仓储,本文取仓储之译。 说到仓储,我们肯定就想到了仓库,仓库一般用来存放货物,而仓库一般由仓库管理员来管理。当工厂生产了一批货物时,只需交给仓库管理员即可,他负责货物的堆放;当需要发货的时候,仓库管理员负责从仓库中捡货进行货物出库处理。当需要库存盘点时,仓库管理员负责核实货物状态和库存。换句话说,仓库管理员负责了货物的出入库管理。通过仓库管理员这个角色,保证了仓库和工厂的独立性,工厂只需要负责生产即可,而至于货物如何存放工厂无需关注。
圣杰
2018/01/11
2.1K0
DDD理论学习系列(12)-- 仓储
2020-5-10-RESTfulAPI中能否使用query string
之前2020-5-6-restful理解 - huangtengxiao和大家介绍了对RESTful的理解。然后就有小伙伴问了我灵魂问题,对于RESTfulAPI设计,是不是不能使用query string?
黄腾霄
2020/06/10
6290
DDD-经典四层架构应用
根据DDD领域驱动设计原则,对应的软件架构也需要做出相应的调整。 我们常用的三层架构模型划分为表现层,业务逻辑层,数据访问层等,在DDD分层结构中既有联系又有区别, 个人认为主要有如下异同:
烂猪皮
2020/11/02
6.7K0
DDD-经典四层架构应用
.NET Core开发实战(第26课:工程结构概览:定义应用分层及依赖关系)--学习笔记
源码链接: https://github.com/witskeeper/geektime/tree/master/microservices
郑子铭
2021/01/13
5600
.NET Core开发实战(第26课:工程结构概览:定义应用分层及依赖关系)--学习笔记
DDD领域驱动设计实战-分层架构及代码目录结构
DDD并没有给出标准的代码模型,不同的人可能会有不同理解。 按DDD分层架构的分层职责定义,在代码模型里分别为用户接口层、应用层、领域层和基础层,建立了 interfaces、application、domain 和 infrastructure 四个一级目录。
JavaEdge
2022/11/30
9K0
DDD领域驱动设计实战-分层架构及代码目录结构
后端开发实践系列——领域驱动设计(DDD)编码实践
的确,很多时候软件的业务逻辑是无法通过推理而得到的,有时甚至是被臆想出来的。这样的结果使得原本已经很复杂的业务变得更加复杂而难以理解。而在具体编码实现时,除了应付业务上的复杂性,技术上的复杂性也不能忽略,比如我们要讲究技术上的分层,要遵循软件开发的基本原则,又比如要考虑到性能和安全等等。
ThoughtWorks
2019/08/01
1.4K0
后端开发实践系列——领域驱动设计(DDD)编码实践
关于Repository模式
本文转载:http://www.cnblogs.com/dudu/archive/2011/05/25/repository_pattern.html
跟着阿笨一起玩NET
2018/09/19
2.3K0
DDD落地之仓储
hello,everyone。又到了周末了,没有出去玩,继续肝。从评论与粉丝私下的联系来看,大家对于DDD架构的热情都比较高。但是因为抽象化的概念较多,因此理解上就很困难。
柏炎
2022/08/23
1.2K0
DDD落地之仓储
DDD之Repository对象生命周期管理
在DDD中Repository是一个相当重要的概念。聚合是战略与战术之间的交汇点。而管理聚合的正是Repository。
码农戏码
2022/11/18
7860
DDD之Repository对象生命周期管理
2020-5-16-理解Graphql
之前2020-5-6-restful理解 - huangtengxiao和大家提及了RESTfulAPI的一个弊端,就是接口膨胀。
黄腾霄
2020/06/10
6950
领域驱动设计(DDD)实践之路(一)
领域驱动设计(Domain Driven Design,DDD)其实并非新理论,大家可以看看 Eric Evans 编著的《领域驱动设计》原稿首版是2003年,距今已十余年时间。与现在的分布式、微服务相比,绝对是即将步入中年的“老家伙”了。
2020labs小助手
2020/02/24
1.5K0
人人都在跟风学微服务,却不知道DDD领域驱动设计?
最先介绍领域驱动设计(domain-driven design)的是在程序员 Eric Evans 2004年出版的《领域驱动设计:复杂软件核心复杂应对之道》书籍中,领域驱动设计是领域概念的扩展和应用,并且将它应用在软件开发中。它的目标是将软件相关部分连接到不断发展的模型中,以此更容易创建复杂的应用。
Lvshen
2022/05/05
4750
人人都在跟风学微服务,却不知道DDD领域驱动设计?
【深度解析】DDD领域驱动设计,分层架构秘籍大公开!让你的设计更上一层楼!
将领域模型和业务逻辑分离出来,并减少对基础设施、用户界面甚至应用层逻辑的依赖,因为它们不属业务逻辑。将一个夏杂的系统分为不同的层,每层都应该具有良好的内聚性,并且只依赖于比其自身更低的层。
程序视点
2025/01/04
3310
DDD落地,如何持久化聚合
聚合是一组始终需要保持一致的业务对象。因此,我们作为一个整体保存和更新聚合,以确保业务逻辑的一致性。聚合是 DDD 中最为重要的概念,即使你不使用 DDD 编写代码也需要理解这一重要的概念 —— 部分对象的生命周期可以看做一个整体,从而简化编程。一般来说,我们需要对聚合内的对象使用 ACID 特性的事务。最简单的例子就是订单和订单项目,订单项目更新必须伴随订单的更新,否则就会有总价不一致之类的问题。订单项目需要跟随订单的生命周期,我们把订单叫做聚合根,它就像一个导航员一样
ThoughtWorks
2021/11/19
2.9K1
DDD落地,如何持久化聚合
[半翻] 设计面向DDD的微服务
许多技术概念和模式,例如充血模型(对应我们常写贫血模型)、值对象、聚合和聚合根规则。
有态度的马甲
2020/05/04
7340
2020-5-11-HATEOAS简介
之前2020-5-6-restful理解 - huangtengxiao和大家介绍了对RESTful的理解。今天和大家介绍下RESTful中最重要的一个概念HATEOAS。
黄腾霄
2020/06/10
7970
熬夜整理的2W字DDD学习笔记
领域可以进一步划分为子领域。我们把划分出来的多个子领域称为子域,每个子域对应一个更小的问题域或更小的业务范围。领域可以拆分为多个子领域。一个领域相当于一个问题域,领域拆分为子域的过程就是大问题拆分为小问题的过程。
BookSea
2024/04/17
3500
熬夜整理的2W字DDD学习笔记
DDD领域驱动设计实战-分层架构
整洁架构、CQRS、六边形架构等微服务架构都旨在“高内聚低耦合”。那DDD分层架构又如何?
JavaEdge
2021/01/22
2K0
DDD领域驱动设计实战-分层架构
相关推荐
2020-5-7-规约模式(specification)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档