关于DAO数据访问对象设计其实是关于GoFrame框架工程化实践中比较重要一块设计。
DAO设计结合GoFrame的ORM组件性能和易用性都很强，可以极大提高开发和维护效率。看完本章节内容之后，小伙伴们应该能够理解并体会到使用DAO数据库访问对象设计的优点。
一、现有ORM使用示例
1、需要定义模型
用户基础表（仅作演示，真实的表有数十个字段）
医生信息表（仅作演示，真实的表有上百个字段）
2、GRPC接口实现示例
一个简单的GRPC查询信息接口。
一个简单的GRPC数据查询接口
二、现有痛点描述
1、必须要定义tag关联表结构与struct属性，无法做到自动映射
表字段与实体对象属性名称之间原本就有一定的关联规则，没有必要定义和维护大量的tag定义。
大量非必要的tag定义，用于指定数据表字段到实体对象属性映射
2、不支持通过返回对象指定需要查询的字段
无法通过返回的对象数据结构指定查询字段，要么只能SELECT * ，要么只能通过额外的方法手动录入查询字段，效率很低下。
常见的SELECT *操作，无法根据接口对象指定查询字段
3、无法对输入对象属性名称进行自动字段过滤
定义了输入与输出数据结构，输出的数据结构已经包含我们需要查询的字段名称。开发者输入定义的返回对象，期望在查询的时候仅查询我需要的字段名称，多余的属性则不会执行查询，自动过滤掉。
4、需要创建中间查询结果对象执行赋值转换
查询结果不支持struct智能转换，需要额外定义一个中间model模型，再通过其他工具进行复制，效率低。
存在中间临时的模型对象，用于承接查询结果及返回结构对象赋值转换
5、需要提前初始化返回对象，不管有无查询到数据
这种方式不仅不优雅，对性能也有影响，还对GC不太友好。期望查询到数据时再自动创建返回对象，没有查询到数据时什么都不要做。
需要预先初始化返回对象，不管有无查询到数据
6、通篇使用底层裸DB对象操作，没有DAO对象封装操作
大部分的Golang初学者似乎都倾向于使用一个全局的DB对象，在查询的时候通过DB对象生成特定表的Model对象再执行CURD操作，这是一种面向过程的使用方式。这种方式并没有代码分层的设计可言，使得数据操作和业务逻辑高度耦合。
原始数据库对象操作方式，没有DAO封装
7、随处可见的字符串硬编码，如表名和字段的硬编码
举个例子，userId这个字段假如一不小心写成了UserId或者userid，测试的时候如果没有完全覆盖到，在一定的条件下才触发查询操作，是不是会造成新的一场事故呢？
大量的字符串硬编码
8、底层ORM引起太多的指针属性定义
指针属性对象为业务逻辑处理埋下隐患，开发者在代码逻辑中需要在指针与属性之间来回切换，特别是一些基础类型往往需要通过重新取值的方式传递参数。如果输入参数是interface{}类型，那么更容易引起BUG
BUG示例，指针属性使用不当，引起地址比较逻辑错误。
同时也影响了业务模型结构体定义设计，对开发者造成了错误习惯引导（上层业务模型的指针属性往往是为了迎合底层数据表实体对象，方便数据传递）。
值得注意一个常见错误，就是将底层数据实体模型当做顶层业务模型使用。特别是在底层数据实体对象使用指针属性的场景下，该问题十分明显。
9、可观测性的支持：Tracing、Metrics、Logging
数据库ORM作为业务项目最关键核心的组件，可观测性的支持至关重要。但是大多数被认为奉承所谓做得越少越”专业”的ORM组件却不曾深谙此道。
10、数据集合与代码数据实体结构不一致
当通过人工维护数据实体结构时，数据集合与代码数据实体结构往往会出现不一致的风险，开发和维护成本高。
三、改进方案设计
1、查询结果对象无需特殊标签定义，全自动关联映射
2、支持根据指定对象自动识别查询字段，而不是全部SELECT *
3、支持根据指定对象自动过滤不存在的字段内容
4、使用DAO对象封装代码设计，通过对象方式操作数据表
5、DAO对象将关联的表名及字段名进行封装，避免字符串硬编码
6、无需提前定义实体对象接受返回结果，无需创建中间实体对象用于接口返回对象的赋值转换
7、查询结果对象无需提前初始化，查询到数据时才会自动创建
8、内置支持OpenTelemetry标准，实现可观测性，极大提高维护效率、降低成本
9、支持SQL日志输出能力，支持开关功能
10、数据模型、数据操作、业务逻辑解耦，支持Dao及Model代码工具化自动生成，保证数据集合与代码数据结构一致，提高开发效率，便于规范落地
11、等等。
采用DAO设计改进后的代码示例
作者：terry，如若转载，请注明出处：https://www.web176.com/goframe/21146.html
支付宝 
微信 