Skip to end of metadata
Go to start of metadata

在之前的章节 代码分层设计对象封装设计 中都有提及到"模型"的概念。

这一章节,我们集中介绍一下在goframe中关于模型的定义以及对应的管理。

一、数据模型

数据模型分为两类:持久化数据模型自定义数据模型,由model模型层统一管理。

持久化数据模型

持久化的数据模型又可以叫做数据集合模型,主要是来自于底层持久化数据库的数据结构,例如:MySQLRedisMongoDBKafka等等。这部分数据结构是由第三方系统维护的,可以通过工具对其集合数据结构进行识别,并自动生化成对应的程序数据模型代码。这部分数据模型的代码通常位于/app/model/internal目录下,开发者一般不需要手动在程序中维护这部分数据模型。

持久化数据模型示例

持久化数据模型往往被model层聚合、嵌套使用并且可被自定义扩展、覆盖数据结构,也可以被service层直接引用。

持久化数据模型使用示例

自定义数据模型

自定义数据模型是需要开发者自行维护的模型,模型代码通常位于/app/model目录下,常用于以下几种用途:

  • 对持久化数据模型的封装,例如:扩展、覆盖。
  • 对持久化数据模型的裁剪,例如:针对特定业务场景,基于持久化数据模型的字段进行裁剪后重新组织。
  • 自定义的数据结构,例如,自定义的持久化数据模型(如KafkaRedis等数据库不支持自动生成/app/model/internal代码的场景)。

自定义数据模型示例

二、业务模型

业务模型主要包含两类:接口输入/输出模型与业务输入/输出模型,由model模型层统一管理。

接口输入/输出模型

接口输入/输出模型用于系统/服务间的接口交互,被api接口层调用。

接口输入模型示例

接口输出模型示例

业务输入/输出模型

业务输入/输出模型用于进程内部模块/组件之间的方法调用交互,特别是api->service之间的调用。

业务输入模型与业务输出模型示例

三、其他模型

上面我们讲到的都是由model模型层维护的公共模型,但部分场景下还存在内部私有的模型,用于模块内部调用,不对外公开。



Content Menu

  • No labels

5 Comments

  1. 强哥,接口的req rsp是否可以考虑提到另外的地方,混在model里,不太好管理查询,可以考虑弄个 msg/request  msg/response,或者考虑放到api/msg/xxxx下, 因为这个和api层是强关联的

    1. 哈哈,我看你提了两个问题都是提到了the very point上,看样子大佬也是过来人。当然,考虑过,现在的这个代码管理方式算是比较务实和简便的方式,大佬和萌新都好理解。统一放model中管理确实会引起一些混淆,不过也是有利有弊,这种常见问题具体在这篇文章中也有介绍过:代码分层设计

  2. 强哥,笔误了:接口输入/输入模型用于   和   业务输入/输入模型

    新版本学习中,收获满满。

  3. 需要提前初始化返回对象,不管有无查询到数据

    我同意常用的orm会有对象转换,但这个里面变量在函数的最开始初始化的例子,不是go语言的惯用写法吧

  4. xx

    这个mongodb怎么用呀? 文档里没找到。。。