您现在的位置是:首页 > 技术教程 正文

如何站在开发者的角度理解框架的设计思想?

admin 阅读: 2024-03-31
后台-插件-广告管理-内容页头部广告(手机)

感谢支持

我已经在CSDN发布了100多篇原创文章,如果你读过我的文章,欢迎点击下方的链接,帮我五星评价一下,谢谢。

很简单,点击下图,像截图一样五星评价一下就可以了

有问必答

最近有好多读者私信我,为什么选择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地址

因为内容比较长且硬核,所以我决定分两篇文章分享:

  1. 这篇文章重点:介绍GoFrame V2的新特性,和V1相比有哪些优势?最大的变化是什么?

  2. 下一篇文章会分享一下:我从V1升级到V2的踩坑之旅,相信对很多小伙伴都有帮助。

这个经历实属不易,希望小伙伴们可以点赞、关注、转发一波。

适合看的人群

  1. 掌握Go基础后,想用成熟框架开发项目的伙伴,建议读完我的文章之后,直接使用GoFrame最新的V2版本实战开发
  2. 目前在用V1版本,有意愿但是没有大量精力学习V2新特性的伙伴,担心升级问题太高不敢贸然升级的伙伴们。
  3. 想提高自己学习新知识效率的小伙伴,欢迎复刻我的这种实践方式。

站在开发者的角度

不管你是哪种人群,都建议先花时间仔细阅读官方文档,尤其是 框架介绍这部分。

区别于官方文档,这篇文章会结合我自己的经验,站在框架使用者的角度,帮大家更快更好的理解Goframe V2版的设计思路,基于V2版本如何更好的进行商业项目的开发。

踩的坑

在我升级版本的过程中发现:一定要先了解清楚V2的新特性,然后再从V1升级到V2,否则升级到一半会出现无从下手的问题:

  1. 因为通过V2版本的CLI工具生成的dao、model,和V1版本是不一致的:废弃了gmvc模块等,也引入了新的模块。

  2. V2版本支持gf gen service的方式生成service层,统一我们接口逻辑的实现方式,引入了logic层和service层的概念

结合自己的升级经历,分享给大家学习GoFrame V2必知必会的知识点:

必知必会

  1. 项目工程结构发生了变化,且需要按照V2的标准来,因为gf工具生成代码的目录结构发生了改变,更重要的:V2官方建议的目录结构也是我们践行"高内聚低耦合"比较好的工程目录结构。

  2. gf gen dao除了会像V1一样生成dao层和model层,还会另外生成do层和entity层

  3. V2版本的目录结构实践了业务模型和数据模型解耦的思想(也是我认为非常赞的地方)

  4. V2相比于V1会出现方法或者模块废弃的情况,比如废弃了gmvc耦合模块,未来不再进一步支持。同时也为我们提供了更好的实现方式。

  5. V2有点编写“微服务”的意思了,需要服务注册:controller调用一个或多个service实现具体的业务逻辑;但是复杂的业务逻辑又不是在service中实现的,为了解耦,V2版本引入了logic目录,用于编写和复用复杂的业务逻辑。在logic中注册服务,在service中通过接口方式规范logic层要实现的方法。

重中之重

下面再介绍一下我花了很长时间才消化的知识点:

dao代码生成(很重要)

gf gen dao

在业务项目中,官方推荐使用dao/do/entity的方式操作数据库,这些文件都是通过开发工具自动生成的,由开发工具统一维护。

区别于V1版本,V2版本引入了do的概念,为什么这么设计?

在这里我只说结论,文章最后会附上官方链接:

  1. dao层用于数据访问,这是一层抽象对象,用于和底层数据库交互,仅包含最基础的 CURD 方法

  2. model层是结构模型,是数据结构管理模块,管理数据实体对象,以及输入与输出数据结构定义。

    2.1 model中的do是领域对象,用于dao数据操作中业务模型与实例模型转换,由工具维护,用户不能修改。

    2.2 model中的entity是数据模型,数据模型是模型与数据集合的一对一关系,由工具维护,用户不能修改。

后面我会带着大家用实例讲解

服务接口生成(更重要)

gf gen service

服务接口是非常重要的知识点,也是我认为在cli工具支持方面和V1版本最大的区别:

为了降低业务项目内部模块间的耦合,框架将模块间的依赖抽象为了接口,由internal/service包维护。internal/service可以由开发者自定义维护接口,也可以通过internal/logic业务封装的代码按照一定规则自动生成接口代码文件。

实践出真知

看10遍文档,都不如一次动手实践。建议大家和我一起操练起来,欢迎复刻:

我的思路是这样:

  1. 下载官方的示例项目,学习一下官方是怎么写的。

  2. 给自己提需求,参考官方的实现方式,实现自己的业务场景。

  3. 我会带着大家实现经典的电商场景:添加和查询商品信息。

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方法后):

  1. 就在logic层的init函数中实现服务的注册;

  2. 然后去查看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项目的编写流程,我的建议是这样的

整理流程

  1. 设计表结构

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

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

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

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

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

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

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

  9. 在main.go中 加入一行 _ “project-name/internal/logic” (只需写一次)

  10. 在main.go中加入一行 _ “github.com/gogf/gf/contrib/drivers/mysql/v2” (如果你使用的是mysql;只需写一次)

关键流程

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

再次实操

我按照上面这个步骤,编写了查询商品逻辑,整体还是非常顺滑的:

小伙伴们也动手实践吧,欢迎star fork我的开源项目:https://github.com/wangzhongyang007/goframe-shop-v2

带着问题学习

我在编写商品管理需求的时候有些疑惑:

为什么要定义两遍数据结构呢?在api层定义了一遍,在model层又定义了一遍,我写了两遍重复的结构体,意义何在呀?

我静下心来想想,这个设计还是值得好好推敲的,我结合之前的项目经历分享一下我的理解。抛砖引玉,小伙伴们有什么理解欢迎在评论区留言。

之前遇到的问题

我们之前在在开发商品中心统一入库时就遇到了难以维护的问题,原因就是业务逻辑和数据处理逻辑耦合在一起。

随着业务的复杂度越来越高,项目维护成本越来越高,甚至达到了难以维护的程度。

我们是如何解决的呢?

解决办法和GoFrame的数据模型和业务模型解耦,底层思想是一样的:

我们把复杂的逻辑进行了拆分:定义了业务模块和数据处理模块。

「业务模块」:只处理接收的参数,并不关心如何入库和取值,按照「数据模块」的要求,处理好前端传入的数据,统一结构体传递给「数据模块」即可。

「数据模块」:不需要关心「业务模块」的具体实现,定义了统一的入参标准,要求业务模块按照自己的要求,统一传入数据;数据模块考虑的重点是如何高效的批量插入数据,如何高效的按需取值,并不需要关心多变的业务侧需求。

升华一下

经过对冗余模块的拆解,梳理清楚了「数据模块」和「业务模块」的边界,我们不仅解决了之前项目难以维护的问题,还提高了灵活对接客户需求的能力。

结合自己的项目经历和这次实践V2版本的经历,所以我开篇说:让开发者更好的做到“模块内部高内聚,模块之间松耦合”,是我认为GoFrame V2设计的精髓。

好了,这篇文章就到这里,硬核爆肝5千字,坚持更新实属不易,欢迎大家点赞、评论、转发。

最后

如果你觉得这期内容不错的话,一定要三连支持一波。

下方有我的公众号卡片,欢迎扫码关注,领取免费硬核的编程资料。

标签:
声明

1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。

在线投稿:投稿 站长QQ:1888636

后台-插件-广告管理-内容页尾部广告(手机)
关注我们

扫一扫关注我们,了解最新精彩内容

搜索
排行榜