记一次代码重构

首先我们来看一下目录结构

这个项目采用thinkphp5.0开发,详细的目录结构可在官方文档中查看。

重构前目录结构

├─application
│  ├─admin
│      ├─controller
│      │  ├─AdminUser.php
│      │  ├─Order.php
│      │  ├─User.php
│      │  ├─UserInfo.php
│      ├─model
│          ├─AdminUser.php
│          ├─Order.php
│          ├─User.php
│          ├─UserInfo.php
├─config
├─extend
├─public
···

咋一看这结构,还挺清晰的。但是写到后面代码量越来越多的时候,你会发现多个模块杂糅在一起,有的是逻辑层和控制层也写在一起,有的是模型层的逻辑成写在一起,单个文件也越来越臃肿,维护难度越来越大。虽然大多是历史遗留的问题,我们总得想办法优化她,让她看起来更加漂亮,更好维护。

开始化妆

重构后目录结构

├─application
│  ├─admin                  后台管理员模块
│  │  ├─controller          控制层,接受数据,返回数据
│  │  │  ├─AdminUser.php
│  │  ├─service             服务层,也是逻辑层,这里写业务逻辑
│  │  │  ├─Api.php          内部api服务,扩模块调用
│  │  │  ├─AdminUser.php
│  ├─common     
│  │  ├─model               公共模型层,全表都在这里,只提供CURD,不含业务逻辑
│  │  │  ├─AdminUser.php
│  │  │  ├─Statistics.php
│  │  │  ├─User.php
│  │  │  ├─UserInfo.php
│  ├─order                  订单模块
│  │  ├─controller
│  │  │  ├─Order.php
│  │  ├─service
│  │      ├─Api.php
│  │      ├─Order.php
│  ├─user                   前台用户模块
│      ├─controller
│      │  ├─User.php
│      │  ├─UserInfo.php
│      ├─service
│          ├─Api.php
│          ├─User.php
│          ├─UserInfo.php
├─config
├─extend
├─public
···

我们采用模块化,将单个模块拆分出来,同时将业务逻辑和对数据的操作解耦。各个模块之间的调用采用统一出口,模块之间也实现了解耦。

分层

  • 控制器层 Controller 提供入口和出口,绝不编写业务逻辑和操作数据库
  • 服务层 Service 编写业务逻辑,Api.php对其他模块输出当前服务层接口
  • 模型层 Model 只应该操作数据库,绝不编写业务逻辑
  • Model 命名同数据库名,驼峰法首字母大写,去掉表前缀,如 User
  • 统一操作Model,已将所有Model移到 application/common/model/

调用

  • Controller 只应该调用 Service
  • Service 只应该调用 Model 和同级(当前模块) Service
  • 跨模块调用只应该调用 Service 层下的Api类
  • Model 只应该操作数据库
  • Validate 验证器编写在 Controller 层

以上也是我在工作中和同事达成一致的规范。

结语

当然,每个团队都有自己的实践,也许并不适用,亦可能有瑕疵。其实只要勤于思考,办法总比困难多。

标签: php thinkphp

发表评论: