大家做 go 后端开发时，都是怎么处理接口操作的原子性的？

[HarrisIce]

背景

我个人习惯，开发带数据库的后端时，gorm 的代码直接写在业务逻辑层，供 gin 的 handler 调用，然后每个业务逻辑层的代码都会带一个tx *gorm.DB（事务），请求到 gin 的 handler 解析完参数后立马开一个 tx ，后边调用的所有业务逻辑代码都带上 tx ，以便一步失败后能够直接 rollback 掉整个请求所有已经执行的业务逻辑。

但是，实际工作中也见过很多大佬写的代码，包括一些开源项目，实际上看到的大家的 dao 封装时根本都不传 tx ，也没怎么见到过在接口做原子性的，一般都是在 dao 封装的时候保证这个函数中涉及的查询和操作整体原子。

疑问

1. 像我那样的“接口原子性”有实际意义吗？ 99%的场景其实没用么？
2. go 的 database 框架中的 tx ，reddit 确实有见到过 best practice 把 tx 在整个 gin 的 handler 传做接口原子的，这个思路是对的吗？
3. 顺带问个 gorm 的问题，你们用 gorm 的话，还会把它再封装一层 dao 么，还是直接放到业务逻辑部分的代码中？

[nodesolar]

1. 事务
2. 最终一致性

[distleilei]

@EchoGroot 老哥 发现疑似 bug https://github.com/EchoGroot/kratos-examples/blob/47a4d89f0e4f295bab64d654b6f4571247653418/pkg/gormx/repo/base_repo.go#L288

[EchoGroot]

@distleilei 没看出啥，麻烦详细说下

[skyqqcc581]

题主想表达的应该是，一个 http 请求 可能涉及多个事务，假设
A B 事务成功
C 事务失败时 是否应该把 A B 一起回滚？

因为假设封装了 dao 实现这个并不容易

所以直接在整个 http 请求的生命周期里用同一个事务，假设生命周期内存在任意错误，则全部回滚吧？

[Makabaka01]

gorm 正常用还是要封装一下的，但是你没必要自己写啊，人家提供了 gen 工具，帮你生成 repo https://gorm.io/gen/index.html