一、基本介绍

信息时代，数据是十分重要的，数据操作是十分敏感的，因此GoFrame框架对于数据操作管理的工程化思路是严谨的。我们提供了必要的ORM抽象、必要的DAO封装、必要的工程化规范约束。同时，我们并不会采用八股文设计，而是依旧保持简便、灵活、易扩展的工程设计思路。

二、工程化痛点

在一些严谨的业务项目中，已经有了ORM&DAO抽象、并且项目已有初步工程化设计的前提，依旧存在以下常见的痛点。

当在代码中手动维护数据集合对应的数据结构时，这个坑就算挖好了，就看后面谁掉进去了。

2、数据模型与业务模型模糊不清

  • 在model中既有业务相关的数据结构（业务模型），又有数据集合对应的数据结构（数据模型），如何高效隔离和管理呢？
  • 在业务流程中，将数据模型当做业务流程的输入参数使用。甚至，将数据模型直接嵌入到API接口输入数据结构定义中（总是想法设法将数据模型用到业务模型中）。

3、DAO层沉淀太多的业务逻辑封装

您是否有一种感觉，只要是数据操作，都有理由往DAO里面丢？

您有可能认为这么做是对的，但是不明确的数据结构都意味着成本和风险。任何的操作，都应当能够明确输入/输出，否则都是不严谨的，对待数据的操作尤其应当严谨。

5、数据操作权限开放，项目任何地方都可以随意调用

数据的操作权限应当尽可能收口，如果过于开放那么当业务及人员复杂之后，项目的维护成本和风险都会曲线增加。

6、从顶层业务到底层数据集合操作，通篇使用同一个数据结构

  • 方法参数定义不明确，不明确的定义意味着会增加额外的协作成本，额外的不明确风险
  • 同一数据结构与多数方法形成耦合，数据结构的任一变动将会影响所有相关方法

三、工程化改进

通过工具自动化实现数据集合到数据模型的代码生成，避免人工维护造成的不同步。

2、数据与业务模型的隔离

将数据模型通过entity包维护，业务模型通过model包维护，通过不同的包职责来做区分。数据模型由工具化维护，业务模型根据业务场景由开发者定义和维护。

3、自动化的DAO代码管理

通过工具自动化实现数据集合的DAO代码生成，提高生产效率。DAO中只有自动化生成的基础数据操作，不封装特定业务逻辑。

5、对数据操作权限进行收口

由于数据操作已经由DAO包进行了统一维护，通过将DAO包迁移到了Service层的internal目录下，实现项目工程下仅仅只有Service层的代码可以通过执行数据操作。