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

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[3]
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层，定义请求和响应的结构体