我们都知道，开发业务项目离不开数据库操作组件的使用，数据库是绝大部分业务项目的核心，这也是"CRUD工程师"戏称的由来。业务项目在进行数据库操作时，比较low的方式是直接Open/New然后各种SQL字符串操作一把梭。稍微正常一点的项目可能会考虑物色或者自己封装一层ORM抽象，提高CRUD效率，降低数据操作风险。再严谨一点的项目可能会在项目工程管理上考虑下，再进一步增加DAO/DTO/VO之类的设计模式和概念。
信息时代，数据是十分重要的，数据操作是十分敏感的，因此GoFrame框架对于数据操作管理的工程化思路是严谨的。我们提供了必要的ORM抽象、必要的DAO封装、必要的工程化规范约束。同时，我们并不会采用八股文设计，而是依旧保持简便、灵活、易扩展的工程设计思路。
在一些严谨的业务项目中，已经有了ORM&DAO抽象、并且项目已有初步工程化设计的前提，依旧存在以下常见的痛点。
当在代码中手动维护数据集合对应的数据结构时，这个坑就算挖好了，就看后面谁掉进去了。
混淆了数据模型与业务的职责，并将数据模型与业务逻辑、接口定义形成了耦合，耦合越大，相关方法、接口维护的成本越高，对数据模型改动产生的风险也越大。常见痛点：
您是否有一种感觉，只要是数据操作，都有理由往DAO里面丢？
您有可能认为这么做是对的，但是不明确的数据结构都意味着成本和风险。任何的操作，都应当能够明确输入/输出，否则都是不严谨的，对待数据的操作尤其应当严谨。
数据的操作权限应当尽可能收口，如果过于开放那么当业务及人员复杂之后，项目的维护成本和风险都会曲线增加。
常见的问题，是设计一个大的结构体，例如数据模型（更有甚者，将属性全部设计为指针或者interface{}），从顶层业务到底层数据操作层层透传，方法逻辑根据是否输入特定的属性来判断传参。会造成什么问题呢：
service层的方法）通过工具自动化实现数据集合到数据模型的代码生成，避免人工维护造成的不同步。
将数据模型通过entity包维护，业务模型通过model包维护，通过不同的包职责来做区分。数据模型由工具化维护，业务模型根据业务场景由开发者定义和维护。
通过工具自动化实现数据集合的DAO代码生成，提高生产效率。DAO中只有自动化生成的基础数据操作，不封装特定业务逻辑。
避免数据模型直接被当做DAO参数使用，避免踩坑。GoFrame框架引入了DO包，在DAO操作时自动化转换为数据集合对应的数据结构，提高DAO操作的效率，降低操作风险。
由于数据操作已经由DAO包进行了统一维护，通过将DAO包迁移到了Service层的internal目录下，实现项目工程下仅仅只有Service层的代码可以通过DAO执行数据操作。
备案信息： 粤ICP备15087711号-2
Copyright © 2008-2024 啊嘎哇在线工具箱 All Rights.
本站所有资料来源于网络，版权归原作者所有，仅作学习交流使用，如不慎侵犯了您的权利，请联系我们。