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

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

一、数据模型

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

持久化数据模型

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

数据模型与业务模型 - 图1持久化数据模型示例

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

数据模型与业务模型 - 图2

数据模型与业务模型 - 图3

持久化数据模型使用示例

自定义数据模型

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

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

数据模型与业务模型 - 图4

数据模型与业务模型 - 图5自定义数据模型示例

二、业务模型

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

接口输入/输出模型

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

数据模型与业务模型 - 图6接口输入模型示例

数据模型与业务模型 - 图7

接口输出模型示例

业务输入/输出模型

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

数据模型与业务模型 - 图8

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

三、其他模型

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

Content Menu