Go 工程化之如何优雅的写出 Repo 层代码

2023-02-28

方法 ctx repo

上篇文章中我们提到了事务的几种解决方案，可以避免在repo中写很多不同事务的方法，这篇我们看一下怎么让repo层的代码看起来优雅一点还是以获取一篇文章为例，我们在获取文章的时候大部分时候可能都是通过id获取的，但是我们也可能通过标题等其它信息获取文章的数据，这时候我们的repo层代码怎么写呢?最简单

上篇文章中我们提到了事务的几种解决方案，可以避免在 repo 中写很多不同事务的方法，这篇我们看一下怎么让 repo 层的代码看起来优雅一点

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

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

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

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

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

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

DBOption

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

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) 
} 
1.
2.
3.
4.
5.
6.
7.

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

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

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

优点

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

// 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))) 
} 
1.
2.
3.
4.
5.
6.
7.
8.
9.

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

// 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 
} 
1.
2.
3.
4.
5.
6.
7.
8.
9.

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

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

// 这里以创建为例 
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 
} 
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

总结

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

type DBOption func(*gorm.DB) *gorm.DB 
// IArticleRepo IArticleRepo 
type IArticleRepo interface { 
 WithByID(id uint) DBOption 
 WithByTitle(title string) DBOption 
 GetArticle(ctx con 
1.
2.
3.
4.
5.
6.

优点

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

缺点