惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
L
LINUX DO - 最新话题
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Forbes - Security
Forbes - Security
博客园 - 司徒正美
Hugging Face - Blog
Hugging Face - Blog
W
WeLiveSecurity
Jina AI
Jina AI
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
N
News and Events Feed by Topic
V
V2EX
Stack Overflow Blog
Stack Overflow Blog
Engineering at Meta
Engineering at Meta
PCI Perspectives
PCI Perspectives
Martin Fowler
Martin Fowler
T
The Exploit Database - CXSecurity.com
F
Full Disclosure
WordPress大学
WordPress大学
S
Security Affairs
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
S
SegmentFault 最新的问题
P
Privacy International News Feed
IT之家
IT之家
M
MIT News - Artificial intelligence
G
GRAHAM CLULEY
Hacker News: Ask HN
Hacker News: Ask HN
D
DataBreaches.Net
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Google Online Security Blog
Google Online Security Blog
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
C
Check Point Blog
美团技术团队
Security Latest
Security Latest
Cyberwarzone
Cyberwarzone
N
News and Events Feed by Topic
MyScale Blog
MyScale Blog
H
Help Net Security
宝玉的分享
宝玉的分享
The Hacker News
The Hacker News
The Last Watchdog
The Last Watchdog
The Cloudflare Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
爱范儿
爱范儿
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
I
Intezer
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
AI
AI
I
InfoQ
N
News | PayPal Newsroom
TaoSecurity Blog
TaoSecurity Blog

Mohuishou

如何实现支持多集群的 Kubernetes Operator? 第三方应用如何调用我们 kubebuilder 生成的自定义资源? Kubernetes 简明教程 k8s job 为何迟迟不能结束? Go 工程化(十) 如何在整洁架构中使用事务? 给博客添加章节目录 使用 Notion Database 管理静态博客文章 一个普通 Go 开发的三年 4. localhost 就一定是 localhost 么? Go可用性(七) 总结: 一张图串联可用性知识点 Go可用性(六) 熔断 10. 总结 9. kubebuilder 进阶: 源码分析 8. kubebuilder 进阶: webhook 7. kubebuilder 进阶: 测试 6. kubebuilder 实战: status & event 5. kubebuilder 实战: CRUD 4. kustomize 简明教程 3. KubeBuilder 简明教程 2. Kind: 如何快速搭建本地 K8s 开发环境? 1. Operator概述: 如何对 Kubernetes 进行扩展 Go可用性(五) 自适应限流 Go可用性(四) 漏桶算法 Go可用性(三) 令牌桶的实现 rate/limt Go可用性(二) 令牌桶原理及使用 Go可用性(一) 隔离设计 Go并发编程(十二) Singleflight Go工程化(九) 项目重构实践 Go工程化(八) 单元测试 Go工程化(七) Go Module Go工程化(六) 配置管理 Go工程化(五) API 设计下: 基于 protobuf 自动生成 gin 代码 Go工程化(四) API 设计上: 项目结构 & 设计 Go工程化(三) 依赖注入框架 wire Go工程化(二) 项目目录结构 Go工程化(一) 架构整洁之道阅读笔记 Go并发编程(十一) 总结 Go并发编程(十) 深入理解 Channel Go并发编程(九) 深入理解 Context Go并发编程(八) 深入理解 sync.Once Go并发编程(七) 深入理解 errgroup Go并发编程(六) 深入理解 WaitGroup Go并发编程(五) 深入理解 sync/atomic Go并发编程(四) 深入理解 Mutex Go并发编程(三) data race Go并发编程(二) Go 内存模型 Go并发编程(一) goroutine Go错误处理最佳实践 微服务(二) 服务发现&多租户 微服务(一) 微服务概览 5. 栈下: 深入理解 defer 4. 栈上: 如何实现一个计算器 Go Struct 初始化风格的抉择 3. 数组下: 使用 GDB 调试 Golang 代码 2. 数组上: 深入理解 slice 1. 链表: 深入理解container/list&LRU缓存的实现 Go设计模式24-总结(更新完毕) Go设计模式23-中介模式 Go设计模式22-解释器模式 Go设计模式21-命令模式 Go设计模式20-备忘录模式 Go设计模式19-访问者模式 Go设计模式18-迭代器模式 Go设计模式17-状态模式 Go设计模式16-职责链模式(Gin的中间件实现) Go设计模式15-策略模式 Go模板模式14-模板模式 Go设计模式13-观察者模式(实现简单的EventBus) Go设计模式12-享元模式 Go设计模式11-组合模式 Go设计模式10-门面模式 Go设计模式09-适配器模式 Go设计模式08-装饰器模式 Go设计模式07-桥接模式 Go设计模式06-代理模式(generate实现类似动态代理) Go设计模式05-创建型模式总结 Go设计模式04-原型模式 Go设计模式03-建造者模式 Go设计模式02-工厂模式&DI容器 笔记-让你最快速地改善代码质量的20条编程规范 Go设计模式01-单例模式 一点拙见-如何写好一个技术预研报告? Go Web小技巧(四)在单个仓库中支持多个 go mod 模块 Go Web 小技巧(三)Gin 参数绑定 Go Web 小技巧(二)GORM 使用自定义类型 Go Web 小技巧(一)简化Gin接口代码 善用工具之postman高级用法概述 go generate and ast hexo-next-algolia-search全文搜索 docker镜像瘦身&优化 GORM避坑指南之含关联关系的更新 Github Actions介绍&自动构建Github Pages博客 在blog中内嵌在线PPT 记一次net http内存泄漏 使用TravisCI自动部署Blog 使用Goland调试Go程序 一个十分边缘的gorm的bug Httprouter介绍及源码阅读 Gin源码阅读 从0.1开始
Go 工程化(十一) 如何优雅的写出 repo 层代码
Mohuishou · 2021-12-27 · via Mohuishou

注:本文已发布超过一年,请注意您所使用工具的相关版本是否适用

本系列为 Go 进阶训练营 笔记,访问 博客: Go进阶训练营, 即可查看当前更新进度,部分文章篇幅较长,使用 PC 大屏浏览体验更佳。

还是以获取一篇文章为例,我们在获取文章的时候大部分时候可能都是通过 id 获取的,但是我们也可能通过标题等其它信息获取文章的数据,这时候我们的 repo 层代码怎么写呢?

最简单的方式,就是我们直接在 repo 这里写两个方法

1
2
3
4
5
// IArticleRepo IArticleRepo
type IArticleRepo interface {
GetArticleByTitle(ctx context.Context, title string) (*Article, error)
GetArticleByID(ctx context.Context, id int) (*Article, error)
}

这样最简单也最直观,但是问题是我们的实际的业务需求往往比我们的例子复杂,如果我们需要通过 id 或者标题获取呢?再添加一个 GetArticleByIDOrTitle ?

这么做的话也不是不行,但是这么做的话就会让我们的 repo 的代码随着时间的增长越来越多不说,命名也是问题,因为组合的方式可能是多种多样的

接下来给大家提供一种我们正在使用的一种思路,利用 Function Options 这种 Go 常见的编程范式,使我们的 repo 更优雅,也可扩展

DBOption

注意: 笔者这里使用的是 GORM,但是这种方式不仅仅适用于 orm 的情况,只是相对方便一点而已

1
2
3
4
5
6
7
8
type DBOption func(*gorm.DB) *gorm.DB

// IArticleRepo IArticleRepo
type IArticleRepo interface {
WithByID(id uint) DBOption
WithByTitle(title string) DBOption
GetArticle(ctx context.Context, opts ...DBOption) (*Article, error)
}

我们定义一个的 DBOption 这个 Option 方法会作为我们 repo 层方法中的最后一个参数,这样我们在定义方法的时候就可以简洁一些,就不必定义很多 GetArticleByXXX 方法了,而是通过定义很多 WithByXXXOption 方法来解决。

这样在 usecase 层,我们只需要这么调用即可

1
2
3
4
func (u *article) GetArticle(ctx context.Context, id int) (*domain.Article, error) {
// 这里可能有其他业务逻辑...
return u.repo.GetArticle(ctx, u.repo.WithByID(uint(id)))
}

优点

复用: 虽然看上去我们只是把 GetArticleByXXX 换成了 WithByXXX 该有的方法并没有变少,但是我们拆分之后会发现很多可以复用的方法,例如 WithByID 这种几乎是每个实体都会有的方法,我们就不用重复写了。

1
2
3
4
5
6
7
8
9
10
11
// GetArticle 和 GetAuthor 都能用上

func (u *article) GetArticle(ctx context.Context, id int) (*domain.Article, error) {
// 这里可能有其他业务逻辑...
return u.repo.GetArticle(ctx, u.repo.WithByID(uint(id)))
}

func (u *article) GetAuthor(ctx context.Context, id int) (*domain.Author, error) {
// 这里可能有其他业务逻辑...
return u.repo.GetAuthor(ctx, u.repo.WithByID(uint(id)))
}

最小化: 这么修改了之后,拆分组合更加方便了,很多查询条件都可以最小化,例如我们可以添加一个 WithSelects 的方法,我们在 usecase 调用的时候就可以传入当前场景只需要关注的字段就可以了

1
2
3
4
5
6
7
8
9
10
// GetArticle 返回文章的同时也需要返回作者的名字
func (u *article) GetArticle(ctx context.Context, id int) (*domain.Article, error) {
article, err := u.repo.GetArticle(ctx, u.repo.WithByID(uint(id)))
if err != nil {
return err
}

article.Author, err = u.repo.GetAuthor(ctx, u.repo.WithByArticleID(id), u.repo.WithBySelects("id", "name"))
return article, err
}

可测性: repo 层的测试会变得更加方便,这样修改之后我们可以将查询条件拆分出来进行测试,会比之前耦合在一起测试简单很多。

抽象: 这种方式可以让我们抽象 CURD 接口更加方便,在 repo 层实现的时候,我们可以直接把 curd 的方法都给抽象出来

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// 这里以创建为例

func (r *userRepo) optionDB(ctx context.Context, opts ...model.DBOption) *gorm.DB {
db := r.db.WithContext(ctx)
for _, opt := range opts {
db = opt(db)
}
return db
}

func (r *userRepo) create(ctx context.Context, data any, opts ...model.DBOption) error {
db := r.optionDB(ctx, opts...)
err := db.Create(data).Error
if err != nil {
return pb.ErrorDbCreateFailf("err: %+v", err)
}
return nil
}

总结

今天给大家介绍了使用 Function Option 的方式来写 repo 层的代码,接下来我们就简单总结一下

1
2
3
4
5
6
7
8
type DBOption func(*gorm.DB) *gorm.DB

// IArticleRepo IArticleRepo
type IArticleRepo interface {
WithByID(id uint) DBOption
WithByTitle(title string) DBOption
GetArticle(ctx context.Context, opts ...DBOption) (*Article, error)
}

优点

  • 复用: 虽然看上去我们只是把 GetArticleByXXX 换成了 WithByXXX 该有的方法并没有变少,但是我们拆分之后会发现很多可以复用的方法,例如 WithByID 这种几乎是每个实体都会有的方法,我们就不用重复写了。
  • 最小化: 这么修改了之后,拆分组合更加方便了,很多查询条件都可以最小化,例如我们可以添加一个 WithSelects 的方法,我们在 usecase 调用的时候就可以传入当前场景只需要关注的字段就可以了
  • 可测性: repo 层的测试会变得更加方便,这样修改之后我们可以将查询条件拆分出来进行测试,会比之前耦合在一起测试简单很多。
  • 抽象: 这种方式可以让我们抽象 CURD 接口更加方便

缺点

  • 最大的缺点就是有的问题在单测可能测试不出来了,usecase 的测试中,repo 层被 mock 掉了,repo 在测试的时候大部分我们只会测试当前的方法,所以 usecase 有使用比较复杂的查询语句的时候,repo 测试最好测一测真实的使用场景,不要仅测试单个 Option 方法

今天的文章就到这里,下篇文章给大家介绍一下 API 定义上的一点小技巧

关注我获取更新

猜你喜欢