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

2.6 我们发现注册路由时，controller.Goods飘红，原因是我们还没有编写这个方法。我们参考示例代码去编写controller层：
我们发现右侧的示例项目，方法内部调用了service中的方法，但是我们目前还没有定义service，怎么办？

文章插图
【站在开发者的角度理解框架的设计思想】
我们先点击示例项目中的user.go，查看一下service中都定义了什么：

文章插图

经过查阅文档得知：
我们需要通过编写logic层实现业务逻辑，通过配置goland插件，自动生成service代码。
这要是官方建议我们的最佳实践：
2.7 导入官方提供的xml文件（只需要配置一次）xml文件地址[4]
强烈建议大家这么操作，经过这个配置在我们编写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的添加商品方法：