站在开发者的角度理解框架的设计思想( 四 ) _框架

使用gf gen dao生成对应的dao/do/model目录代码

编写api层：定义「业务模块」的数据结构，提供对外接口的输入/输出数据结构

编写model层：定义「数据模块」的数据结构，提供对内的数据处理的输入/输出数据结构

编写logic层，自动生成service层代码。（通过配置goland File Watcher自动生成，也可以通过gf gen service手动执行脚本生成，强烈建议前者）

在service层代码生成RegisterXX()方法后，在对应的logic模块注册服务(每个模块只需要写一次)

编写controller层，接收/解析用户输入的参数，调用service层的服务。

注册路由，对外暴露接口，比如这个项目是编写cmd.go文件。

在main.go中加入一行 _ "project-name/internal/logic" （只需写一次）

在main.go中加入一行 _ "github.com/gogf/gf/contrib/drivers/MySQL/v2" （如果你使用的是mysql；只需写一次）

关键流程

上面的步骤只有3~8是每次开发新需求都需要的
步骤1、2设计表结构和自动生成代码很简单，涉及到新增表或者修改表时才需要
步骤9、10在创建项目时编写一次即可

再次实操我按照上面这个步骤，编写了查询商品逻辑，整体还是非常顺滑的：

文章插图

文章插图

小伙伴们也动手实践吧，欢迎star fork我的开源项目：https://github.com/wangzhongyang007/goframe-shop-v2
带着问题学习我在编写商品管理需求的时候有些疑惑：
为什么要定义两遍数据结构呢?在api层定义了一遍，在model层又定义了一遍，我写了两遍重复的结构体，意义何在呀？

文章插图

我静下心来想想，这个设计还是值得好好推敲的，我结合之前的项目经历分享一下我的理解。抛砖引玉，小伙伴们有什么理解欢迎在评论区留言。
之前遇到的问题我们之前在在开发商品中心统一入库时就遇到了难以维护的问题，原因就是业务逻辑和数据处理逻辑耦合在一起。
随着业务的复杂度越来越高，项目维护成本越来越高，甚至达到了难以维护的程度。
我们是如何解决的呢？解决办法和GoFrame的数据模型和业务模型解耦，底层思想是一样的：
我们把复杂的逻辑进行了拆分：定义了业务模块和数据处理模块。
「业务模块」：只处理接收的参数，并不关心如何入库和取值，按照「数据模块」的要求，处理好前端传入的数据，统一结构体传递给「数据模块」即可。
「数据模块」：不需要关心「业务模块」的具体实现，定义了统一的传参标准，要求业务模块按照自己的要求，统一传入数据；数据模块考虑的重点是如何高效的批量插入数据，如何高效的按需取值，并不需要关心多变的业务侧需求。
升华一下经过对冗余模块的拆解，梳理清楚了「数据模块」和「业务模块」的边界，我们不仅解决了之前项目难以维护的问题，还提高了灵活对接客户需求的能力。
结合自己的项目经历和这次实践V2版本的经历，所以我开篇说：让开发者更好的做到“模块内部高内聚，模块之间松耦合”，是我认为GoFrame V2设计的精髓。
好了，这篇文章就到这里，硬核爆肝5千字，坚持更新实属不易，欢迎大家点赞、评论、转发。
参考资料[1]电商前后台系统API: http://github.com/wangzhongyang007/GoFrame-shop
[2]框架介绍: https://GoFrame.org/pages/viewpage.action?pageId=3672399
[3]官方示例GitHub: https://github.com/gogf/gf-demo-user
[4]xml文件地址: https://GoFrame.org/pages/viewpage.action?pageId=49770772&preview=/49770772/49770777/watchers.xml
本文转载自微信公众号「程序员升级打怪之旅」，作者「王中阳Go」