背景

我个人习惯，开发带数据库的后端时，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 么，还是直接放到业务逻辑部分的代码中？