我的书签
添加书签
移除书签关于 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 对象操作，没有对象封装操作
大部分的 Golang 初学者似乎都倾向于使用一个全局的 DB 对象，在查询的时候通过 DB 对象生成特定表的 Model 对象再执行 CURD 操作，这是一种面向过程的使用方式。这种方式并没有代码分层的设计可言， 使得数据操作和业务逻辑高度耦合。
原始数据库对象操作方式，没有 DAO 封装
7、随处可见的字符串硬编码，如表名和字段的硬编码
举个例子， userId 这个字段假如一不小心写成了 UserId 或者 userid，测试的时候如果没有完全覆盖到，在一定的条件下才触发查询操作，是不是会造成新的一场事故呢？
大量的字符串硬编码
8、底层ORM引起太多的指针属性定义
指针属性对象为业务逻辑处理埋下隐患，开发者在代码逻辑中需要在指针与属性之间来回切换，特别是一些基础类型往往需要通过重新取值的方式传递参数。如果输入参数是 interface{} 类型，那么更容易引起 BUG。
BUG 示例，指针属性使用不当，引起地址比较逻辑错误。
同时也影响了业务模型结构体定义设计，对开发者造成了错误习惯引导（上层业务模型的指针属性往往是为了迎合底层数据表实体对象，方便数据传递）。
值得注意一个常见错误，就是将底层数据实体模型当做顶层业务模型使用。特别是在底层数据实体对象使用指针属性的场景下，该问题十分明显。
9、可观测性的支持：Tracing、Metrics、Logging
数据库ORM作为业务项目最关键核心的组件，可观测性的支持至关重要。
10、数据集合与代码数据实体结构不一致
当通过人工维护数据实体结构时，数据集合与代码数据实体结构往往会出现不一致的风险，开发和维护成本高。
三、改进方案设计
1、查询结果对象无需特殊标签定义，全自动关联映射
2、支持根据指定对象自动识别查询字段，而不是全部 SELECT *
3、支持根据指定对象自动过滤不存在的字段内容
4、使用 DAO 对象封装代码设计，通过对象方式操作数据表
5、 DAO 对象将关联的表名及字段名进行封装，避免字符串硬编码
6、无需提前定义实体对象接受返回结果，无需创建中间实体对象用于接口返回对象的赋值转换
7、查询结果对象无需提前初始化，查询到数据时才会自动创建
8、内置支持 OpenTelemetry 标准，实现可观测性，极大提高维护效率、降低成本
9、支持 SQL 日志输出能力，支持开关功能
10、数据模型、数据操作、业务逻辑解耦，支持 Dao 及 Model 代码工具化自动生成，保证数据集合与代码数据结构一致，提高开发效率，便于规范落地
11、等等。
采用 DAO 设计改进后的代码示例
