彩虹女神跃长空，Go语言进阶之Go语言高性能Web框架Iris项目实战-项目结构优化EP05

前文再续，上一回我们完成了用户管理模块的CURD(增删改查)功能，功能层面，无甚大观，但有一个结构性的缺陷显而易见，那就是项目结构过度耦合，项目的耦合性(Coupling)，也叫耦合度，进而言之，模块之间的关系，是对项目结构中各模块间相互联系紧密程度的一种量化。耦合的强弱取决于模块间调用的复杂性、调用模块之间的方式以及通过函数或者方法传送数据对象的多少。模块间的耦合度是指模块之间的依赖关系，包括包含关系、控制关系、调用关系、数据传递关系以及依赖关系。项目模块的相互依赖越多，其耦合性越强，同时表明其独立性越差，愈加难以维护。

项目结构优化

目前IrisBlog项目的问题就是独立性太差，截至目前为止，项目结构如下：

一望而知，前端页面(views)以及静态文件(assets)的工程化尚可，不再需要进行分层操作，但是在后端，虽然模型层(model.go)和工具层(mytool.go)已经分离出主模块，但主要业务代码还是集中在入口文件main.go中：

入口文件main.go承载了太多业务，既需要负责数据库结构体的创建，又得操心模板的渲染和接口逻辑的编写，说白了：泥沙俱下，沉渣泛起。

事实上，像这样把所有代码都堆到一个文件中，还会带来协作问题，比如，当你花了一整天的时间，好不容易完成了一段业务逻辑，也通过了本地测试，准备第二天提交线上测试，但是第二天上班时却发现这个逻辑莫名其妙地开始报错了，这通常是因为有同事在你走后修改了你编写或者依赖的那个模块，归根结底，并不完全是协作的问题，项目结构也是因素之一。

多个研发同时修改了同一个源代码文件。虽然在规模相对较小、人员较少的项目中，这种问题或许并不严重，但是随着项目的增长，研发人员的增加，这种每天早上刚上班时都要经历一遍的痛苦就会越来越多，甚至会严重到让有的团队在长达数周的时间内都不能发布一个稳定的项目版本，因为每个人都在不停地修改自己的代码，以适应其他人所提交的变更，周而复始，恶性循环。

所以我们必须把业务单独抽离出来，比如用户管理其实是后台模块功能，只有特定的管理员才可能在其页面进行操作，所以我们可以单独创建一个控制层：

随后编写后台控制逻辑admin.go:

这里把用户管理页面的解析函数单独抽离在handler包中，注意函数的首字母要进行大写处理，因为首字母小写函数是私有函数，只能在包内使用，无法被别的包调用。

随后改造入口文件main.go逻辑:

路由匹配时，只需要引入handler包中的Admin_user_page函数就可以了。

随后，对路由进行分组优化，同属一个业务的模块绑定在同一个分组中：

如此，业务和路由解析就彻底分开了，结构体创建函数也清爽了不少：

数据层结构优化

业务层进行了拆分，但是数据层还集成在入口文件中main.go:

这里的含义是，一旦进入入口逻辑，就立刻初始化数据库，随后执行业务代码，当业务执行完毕后，利用延迟函数defer关闭数据库链接。

这种逻辑的弊端是，一旦数据库服务挂掉，整个项目服务也会受影响，再者，很多纯静态化页面并不需要数据库链接，每一次都链接数据库，显然是画蛇添足。

所以单独建立数据包：

建立数据层逻辑database.go:

这里我们构建函数Db()，它返回一个数据库操作的结构体指针，专门用来执行数据库操作，需要注意的是，删除函数内之前的延后defer关闭链接函数，否则链接在函数体内就关闭了，调用方就无法使用数据库了。

调用上，直接调用database包中的Db()，就可以直接使用数据库指针了：

随后，继续优化入口文件：

这里优化了main函数，使其逻辑更加简明和清晰。

最后，优化数据层逻辑database.go:

这里我们分别封装mysql和sqlite3数据库指针函数，然后通过switch语句来根据不同的开发环境而进行切换和控制。

至此，项目结构的首次结构性优化就完成了，优化后的结构如下：

结语

为什么我们一开始不直接采用低耦合高内聚的项目架构？因为别人的经验并不是我们的经验，只有真正经历过才是真实的开发经验，项目开发没有标准答案，只有选择，然后承担后果，只有尝试过苦涩的果实之后，下一次才会做出正确的选择。该项目已开源在Github：https://github.com/zcxey2911/IrisBlog ，与君共觞，和君共勉。