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

最近有好多读者私信我，为什么选择GoFrame做电商项目的开发?,原因很简单：,因为我司是用GoFrame做电商业务开发的，而且我司同事基本都是PHP转Go的。GoFrame可以说是非常适合PHPer转Gopher的开发框架。,在入职我司之前，我有使用Gin和go-micro框架，目前也正在学习go-zero。,不管是开发语言还是开发框架，都服务于我们所做的业务，抛开业务去聊语言或者框架都是没有意义的。,使用GoFrame做开源项目的另一个原因是：想体验一下V2版本的新特性，自己的项目怎么做自己能完全说了算，没有历史包袱。,用GoFrame开发商业项目已经很长时间，发现GoFrame的版本更新比较快，社区也非常的活跃。,因为历史原因，我之前一直用V1.16版本做商业项目的开发，虽然个人有比较强的意愿升级到V2。,但是考虑到项目稳定性及开发成本等等原因，商业项目并未升级。这可能也是很多小伙伴面临的问题。,正好前段时间，分享了自己的开源项目【Go WEB进阶实战】基于GoFrame搭建的电商前后台API系统受到了大家的关注和支持，GoFrame的作者也在点赞转发，更受鼓励。,更重要的是：收到了社区里很多小伙伴的建议，最多的建议就是建议我使用V2版本，因为提供了很多新特性，可以更好的实现需求，稳定且高效。,所以，我决定把我开源的项目从V1.16.x版本，升级到最新的V2.2.0版本，踩一下升级的坑，享受一下升级后的快乐。,欢迎小伙伴们加入到我的开源项目中：电商前后台系统API[1]，目前V1版本已经收尾，包括电商项目的常用功能，开发了120多个接口。,V2版本在开发过程中，目前已经开发了30多个接口，计划这个月内开发完毕，也开源出去。欢迎小伙伴们参与共建，也欢迎阅读我的源码，多提宝贵建议：,V2版本GitHub地址,因为内容比较长且硬核，所以我决定分两篇文章分享：,这个经历实属不易，希望小伙伴们可以点赞、关注、转发一波。,不管你是哪种人群，都建议先花时间仔细阅读官方文档，尤其是 框架介绍[2]这部分。,区别于官方文档，这篇文章会结合我自己的经验，站在框架使用者的角度，帮大家更快更好的理解Goframe V2版的设计思路，基于V2版本如何更好的进行商业项目的开发。,在我升级版本的过程中发现：一定要先了解清楚V2的新特性，然后再从V1升级到V2，否则升级到一半会出现无从下手的问题：,结合自己的升级经历，分享给大家学习GoFrame V2必知必会的知识点：,下面再介绍一下我花了很长时间才消化的知识点：,在业务项目中，官方推荐使用dao/do/entity的方式操作数据库，这些文件都是通过开发工具自动生成的，由开发工具统一维护。,区别于V1版本，V2版本引入了do的概念，为什么这么设计？,在这里我只说结论，文章最后会附上官方链接：,后面我会带着大家用实例讲解,gf gen service,服务接口是非常重要的知识点，也是我认为在cli工具支持方面和V1版本最大的区别：,为了降低业务项目内部模块间的耦合，框架将模块间的依赖抽象为了接口，由internal/service包维护。internal/service可以由开发者自定义维护接口，也可以通过internal/logic业务封装的代码按照一定规则自动生成接口代码文件。,看10遍文档，都不如一次动手实践。建议大家和我一起操练起来，欢迎复刻：,官方示例GitHub[3],1.1 下载部署好项目之后，启动：非常顺滑的就启动成功了：,,1.2 请求接口，验证试一下DB是否连接正常。,,1.3 查询数据库，也是有值的。,,验证环境无误，下面开始带着大家参考官方示例实现自己的需求，进而更好的理解V2版本新特性和工程实践。,我们按照官方建议的工程方式去实践，看看会不会踩坑：,,初次尝试，失败，原因是没有修改hack目录下的config.yaml配置文件。,,注意：和V1不同，官方说hack目录的作用是工具脚本，存放项目开发工具、脚本等内容。例如，CLI工具的配置，各种shell/bat脚本等文件。所以我们就不要像V1一样把cli工具的配置文件也写到manifest/config目录中了。,,小技巧，如果我们不指定tables，则生成所有表对应的数据。我是比较喜欢这么操作：因为能避免自己改了多个tables，但是在配置文件中漏写了某个tables导致意料之外的问题。,我会先按照大家容易理解的方式进行编写，文章最后我会分享实践经验：按照什么顺序编写各个模块的代码是比较科学的。,,,我们参考示例代码去编写controller层：,我们发现右侧的示例项目，方法内部调用了service中的方法，但是我们目前还没有定义service，怎么办？,,我们先点击示例项目中的user.go，查看一下service中都定义了什么：,,经过查阅文档得知：,我们需要通过编写logic层实现业务逻辑，通过配置goland插件，自动生成service代码。,这要是官方建议我们的最佳实践：,xml文件地址[4],强烈建议大家这么操作，经过这个配置在我们编写logic层代码的时候，service能自动生成接口定义文件。,当然也可以不配置，只是每一次在开发/更新完成logic业务模块后，都需要手动执行一下 gf gen service 命令。太麻烦了！！！,,,,我们发现：在logic层编写完添加商品逻辑后，在右侧的service层自动生成了代码。,,,答案是：我们要在service层生成RegisterXX()方法后，在对应的业务模块中加上接口的实现注入。,,小提示：该方法每个业务模块加一次即可。,建议大家在编写完第一个logic方法后（或者说service层生成了RegisterXX方法后）：,要成良好的编码习惯，少出bug。,这个文件的作用是：将接口的具体实现，在程序启动时执行注册。,,好了，logic和service到此结束，我们已经完成了业务逻辑的编写。,内容不少，大家可以上划再看一遍这部分内容，消化吸收一下。,我们参考官方提供的controller/user.go 实现了我们自己的 controller/goods.go的添加商品方法：,,,很OK，已经看到了对应的接口。,我们请求接口，添加数据看一下：,,在数据库中也查看到数据：插入成功，流程走通！,,按照上面这个流程走下来，虽然整体跑通了。我个人感觉还是比较混乱的。,我又花了比较长的时间消化吸收了官方文档的工程实践，结合我自己的经验。,我们再来梳理一下V2项目的编写流程，我的建议是这样的：,我按照上面这个步骤，编写了查询商品逻辑，整体还是非常顺滑的：,,,小伙伴们也动手实践吧，欢迎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」，可以通过以下二维码关注。,,转载本文请联系「 程序员升级打怪之旅」公众号。