这是我参与「第三届青训营 -后端场」笔记创作活动的第2篇笔记
使用场景1
最近着手开始做字节青训营最后的那个大作业。作为一个本来是写java的同学，写go的时候总是一股java味，写服务的时候也对模块进行了简单的分层。
我挑几个关键的层拿出来说：
- controller
- vo
- service
- dao
- repository
gorm是在
dao层使用的，用于对数据库的增删改查。在实现repository层向vo层的转换的时候，如果使用scan这个方法就会出现这么一个情况：dao层的代码既调用了vo层的结构体又调用了repository的结构体，这让我觉得项目的结构有些混乱。dao层只和repository层产生联系，controller层只和vo层产生联系，这样的结构才是我理想中的样子。
我个人解决的一个方案是放弃了gorm中的scan，在service层中单独写一个function去实现repository层和vo层之间的转换。
我把这个疑惑也提交到了gorm的GitHub仓库的issues上。
使用场景2
在我写java的日子里，对于数据库，我会选择先讨论好数据库的结构然后通过mybatis-plus这种工具去逆向工程自动生成代码。而在使用的gorm的过程中，我则是先创建好结构体，再通过结构体去生成数据库的表的结构。前者更让开发者把注意力放在数据库上，后者则更让开发者把注意力放在后端的业务上。
就个人而言，在我浅薄的开发经验中，我更喜欢gorm的方式一些，后端的开发体验会更连续一些。mybatis-plus那样的方式去开发，在我设计数据库的时候，我需要在脑中预想一下后端中的类会是什么样的，因为在开发过程中接触的更多的会是后端生成的类。gorm的话就不用先去这样设想，结构体自然而然地先出现了，而且还能直接去思考结构体之间的关系，从而产生了gorm的关联这一设计，数据库那边也会自动地生成一些中间表，这使我的开发体验愉快了很多哈哈哈。
