常用的开发框架并介绍工具（如何站在开发者的角度理解框架的设计思想？）
有问必答
最近有好多读者私信我 ，为什么选择GoFrame做电商项目的开发?
原因很简单：
因为我司是用GoFrame做电商业务开发的 ，而且我司同事基本都是PHP转Go的 。GoFrame可以说是非常适合PHPer转Gopher的开发框架 。
在入职我司之前 ，我有使用Gin和go-micro框架 ，目前也正在学习go-zero 。
不管是开发语言还是开发框架 ，都服务于我们所做的业务 ，抛开业务去聊语言或者框架都是没有意义的 。
使用GoFrame做开源项目的另一个原因是：想体验一下V2版本的新特性 ，自己的项目怎么做自己能完全说了算 ，没有历史包袱 。
前言
让开发者更好的做到“模块内部高内聚 ，模块之间松耦合 ” ，是我认为GoFrame V2设计的精髓 。
用GoFrame开发商业项目已经很长时间 ，发现GoFrame的版本更新比较快 ，社区也非常的活跃 。
因为历史原因 ，我之前一直用V1.16版本做商业项目的开发 ，虽然个人有比较强的意愿升级到V2 。
但是考虑到项目稳定性及开发成本等等原因 ，商业项目并未升级 。这可能也是很多小伙伴面临的问题 。
受到鼓励
正好前段时间 ，分享了自己的开源项目【Go WEB进阶实战】基于GoFrame搭建的电商前后台API系统
受到了大家的关注和支持 ，GoFrame的作者也在点赞转发 ，更受鼓励 。更重要的是：收到了社区里很多小伙伴的建议 ，最多的建议就是建议我使用V2版本 ，因为提供了很多新特性 ，可以更好的实现需求 ，稳定且高效 。
决定升级
所以 ，我决定把我开源的项目从V1.16.x版本 ，升级到最新的V2.2.0版本 ，踩一下升级的坑 ，享受一下升级后的快乐 。
欢迎小伙伴们加入到我的开源项目中：电商前后台系统API ，目前V1版本已经收尾 ，包括电商项目的常用功能 ，开发了120多个接口 。
一起参与
V2版本在开发过程中 ，目前已经开发了30多个接口 ，计划这个月内开发完毕 ，也开源出去 。欢迎小伙伴们参与共建 ，也欢迎阅读我的源码 ，多提宝贵建议：
V2版本GitHub地址
因为内容比较长且硬核 ，所以我决定分两篇文章分享：
这篇文章重点：介绍GoFrame V2的新特性 ，和V1相比有哪些优势？最大的变化是什么？
下一篇文章会分享一下：我从V1升级到V2的踩坑之旅 ，相信对很多小伙伴都有帮助 。
这个经历实属不易 ，希望小伙伴们可以点赞 、关注 、转发一波 。
适合看的人群
掌握Go基础后 ，想用成熟框架开发项目的伙伴 ，建议读完我的文章之后 ，直接使用GoFrame最新的V2版本实战开发 目前在用V1版本 ，有意愿但是没有大量精力学习V2新特性的伙伴 ，担心升级问题太高不敢贸然升级的伙伴们 。 想提高自己学习新知识效率的小伙伴 ，欢迎复刻我的这种实践方式 。站在开发者的角度
不管你是哪种人群 ，都建议先花时间仔细阅读官方文档 ，尤其是 框架介绍这部分 。
区别于官方文档 ，这篇文章会结合我自己的经验 ，站在框架使用者的角度 ，帮大家更快更好的理解Goframe V2版的设计思路 ，基于V2版本如何更好的进行商业项目的开发 。
踩的坑
在我升级版本的过程中发现：一定要先了解清楚V2的新特性 ，然后再从V1升级到V2 ，否则升级到一半会出现无从下手的问题：
因为通过V2版本的CLI工具生成的dao 、model ，和V1版本是不一致的：废弃了gmvc模块等 ，也引入了新的模块 。
V2版本支持gf gen service的方式生成service层 ，统一我们接口逻辑的实现方式 ，引入了logic层和service层的概念
结合自己的升级经历 ，分享给大家学习GoFrame V2必知必会的知识点：
必知必会
项目工程结构发生了变化 ，且需要按照V2的标准来 ，因为gf工具生成代码的目录结构发生了改变 ，更重要的：V2官方建议的目录结构也是我们践行"高内聚低耦合"比较好的工程目录结构 。
gf gen dao除了会像V1一样生成dao层和model层 ，还会另外生成do层和entity层
V2版本的目录结构实践了业务模型和数据模型解耦的思想（也是我认为非常赞的地方）
V2相比于V1会出现方法或者模块废弃的情况 ，比如废弃了gmvc耦合模块 ，未来不再进一步支持 。同时也为我们提供了更好的实现方式 。
V2有点编写“微服务 ”的意思了 ，需要服务注册：controller调用一个或多个service实现具体的业务逻辑；但是复杂的业务逻辑又不是在service中实现的 ，为了解耦 ，V2版本引入了logic目录 ，用于编写和复用复杂的业务逻辑 。在logic中注册服务 ，在service中通过接口方式规范logic层要实现的方法 。
重中之重
下面再介绍一下我花了很长时间才消化的知识点：
dao代码生成（很重要）
gf gen dao
在业务项目中 ，官方推荐使用dao/do/entity的方式操作数据库 ，这些文件都是通过开发工具自动生成的 ，由开发工具统一维护 。
区别于V1版本 ，V2版本引入了do的概念 ，为什么这么设计？
在这里我只说结论 ，文章最后会附上官方链接：
dao层用于数据访问 ，这是一层抽象对象 ，用于和底层数据库交互 ，仅包含最基础的 CURD 方法
model层是结构模型 ，是数据结构管理模块 ，管理数据实体对象 ，以及输入与输出数据结构定义 。
2.1 model中的do是领域对象 ，用于dao数据操作中业务模型与实例模型转换 ，由工具维护 ，用户不能修改 。
2.2 model中的entity是数据模型 ，数据模型是模型与数据集合的一对一关系 ，由工具维护 ，用户不能修改 。
后面我会带着大家用实例讲解
服务接口生成（更重要）
gf gen service
服务接口是非常重要的知识点 ，也是我认为在cli工具支持方面和V1版本最大的区别：
为了降低业务项目内部模块间的耦合 ，框架将模块间的依赖抽象为了接口 ，由internal/service包维护 。internal/service可以由开发者自定义维护接口 ，也可以通过internal/logic业务封装的代码按照一定规则自动生成接口代码文件 。
实践出真知
看10遍文档 ，都不如一次动手实践 。建议大家和我一起操练起来 ，欢迎复刻：
我的思路是这样：
下载官方的示例项目 ，学习一下官方是怎么写的 。
给自己提需求 ，参考官方的实现方式 ，实现自己的业务场景 。
我会带着大家实现经典的电商场景：添加和查询商品信息 。
1. 下载运行官方示例的GitHub
官方示例GitHub
1.1 下载部署好项目之后 ，启动：非常顺滑的就启动成功了：
1.2 请求接口 ，验证试一下DB是否连接正常 。
1.3 查询数据库 ，也是有值的 。
验证环境无误 ，下面开始带着大家参考官方示例实现自己的需求 ，进而更好的理解V2版本新特性和工程实践 。
2. 基于V2编写商品管理
我们按照官方建议的工程方式去实践 ，看看会不会踩坑：
2.1 创建goods表如下：
2.2 通过gf gen dao生成dao和model
初次尝试 ，失败 ，原因是没有修改hack目录下的config.yaml配置文件 。
注意：和V1不同 ，官方说hack目录的作用是工具脚本 ，存放项目开发工具 、脚本等内容 。例如 ，CLI工具的配置 ，各种shell/bat脚本等文件 。所以我们就不要像V1一样把cli工具的配置文件也写到manifest/config目录中了 。
2.3 搞定 ，成功生成 。
小技巧 ，如果我们不指定tables ，则生成所有表对应的数据 。我是比较喜欢这么操作：因为能避免自己改了多个tables ，但是在配置文件中漏写了某个tables导致意料之外的问题 。
下面开始正式撸代码了：
我会先按照大家容易理解的方式进行编写 ，文章最后我会分享实践经验：按照什么顺序编写各个模块的代码是比较科学的 。
2.4 首先我们实现api层 ，定义请求和响应的结构体
2.5 我们在cmd中注册Goods相关的路由
2.6 我们发现注册路由时 ，controller.Goods飘红 ，原因是我们还没有编写这个方法 。
我们参考示例代码去编写controller层：
我们发现右侧的示例项目 ，方法内部调用了service中的方法 ，但是我们目前还没有定义service ，怎么办？
我们先点击示例项目中的user.go ，查看一下service中都定义了什么：
经过查阅文档得知：
我们需要通过编写logic层实现业务逻辑 ，通过配置goland插件 ，自动生成service代码 。
这要是官方建议我们的最佳实践：
2.7 导入官方提供的xml文件（只需要配置一次）
xml文件地址
强烈建议大家这么操作 ，经过这个配置在我们编写logic层代码的时候 ，service能自动生成接口定义文件 。
当然也可以不配置 ，只是每一次在开发/更新完成logic业务模块后 ，都需要手动执行一下 gf gen service 命令 。太麻烦了！！！
2.8 我们参考右侧的示例 编写商品goods的logic代码 ，处理业务逻辑：
2.9 经测试我发现：在编写logic逻辑后 ，就自动在service层生成了对应的goods文件和方法 ，非常方便 。
2.10 我们再继续写添加商品逻辑和查看商品逻辑
我们发现：在logic层编写完添加商品逻辑后 ，在右侧的service层自动生成了代码 。
2.11 细心的同学可能发现了service层的RegisterGoods方法 ，这是干嘛用的呢？
答案是：我们要在service层生成RegisterXX()方法后 ，在对应的业务模块中加上接口的实现注入 。
小提示：该方法每个业务模块加一次即可 。
建议大家在编写完第一个logic方法后（或者说service层生成了RegisterXX方法后）：
就在logic层的init函数中实现服务的注册；
然后去查看logic.go文件是否添加了相关的依赖 ，没有的话也可以手动添加一下；
要成良好的编码习惯 ，少出bug 。
2.12 我们查看logic目录下的logic.go文件 ，发现已经自动添加了我们本次编写的goods相关的import：
这个文件的作用是：将接口的具体实现 ，在程序启动时执行注册 。
好了 ，logic和service到此结束 ，我们已经完成了业务逻辑的编写 。
内容不少 ，大家可以上划再看一遍这部分内容 ，消化吸收一下 。
2.13 咱们回过头来 ，继续编写controller层的代码：
我们参考官方提供的controller/user.go 实现了我们自己的 controller/goods.go的添加商品方法：
2.14 到这里 ，我们已经完成了新需求的编写 ，启动服务查看一下效果：
很OK ，已经看到了对应的接口 。
编码完毕 ，测试一下：
我们请求接口 ，添加数据看一下：
在数据库中也查看到数据：插入成功 ，流程走通！
反思回顾
按照上面这个流程走下来 ，虽然整体跑通了 。我个人感觉还是比较混乱的 。
我又花了比较长的时间消化吸收了官方文档的工程实践 ，结合我自己的经验 。
我们再来梳理一下V2项目的编写流程 ，我的建议是这样的：
整理流程
设计表结构
使用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千字 ，坚持更新实属不易 ，欢迎大家点赞 、评论 、转发 。
创心域SEO版权声明：以上内容作者已申请原创保护，未经允许不得转载，侵权必究！授权事宜、对本内容有异议或投诉，敬请联系网站管理员，我们将尽快回复您，谢谢合作！