一个项目的组成 - youngperson/study-100 GitHub Wiki

项目的组成

  • 路由框架(比如gin、echo、beego、yii2)
  • 操作各种数据库(go-xorm、orm)
  • 包的管理引用(govendor、composer)
  • 配置文件/配置的管理(toml、yaconf)
  • 日志的记录(zerolog、monolog)
  • 从PHP转Go2个多月后体会到了语言之间的思路是相通的
  • 基于上面的这些(其实就是一个base框架了)，我们只需要去写我们的具体业务就好了
  • 写框架的时候会用了设计模式，写出来的框架要易用、高性能、可以扩展性好
  • 去读一个框架，也是需要去关注路由、操作数据库、包的管理、配置、日志怎么实现的，又是怎么串在一起协调完成工作的

学习资料

base框架目录

[Project Name]
├── base/public    	服务使用的静态资源，如定义的一些常量
├── common        	服务自用的通用函数，更加通用的函数放在 common 库中
├── dao               	数据抽象层，对数据的CRUD操作放这里
├── doc               	服务详细的文档，包括更新修复提交等记录
├── docker          	Docker 相关的启动文件
├── models          	数据模型，一般是从数据库生成的数据结构
├── service           	业务逻辑(调度、判断、校验等等)，根据情况分文件夹
├── vendor          	依赖库
├── build.sh         	仿真/线上构建脚本
├── conf.toml       	本地测试的配置脚本
├── main.go         	服务的入口文件
├── readme.md    	服务简单的说明，简要说明服务功能，依赖关系等
└── api               	服务 API 接口定义，根据业务/版本号分文件夹(api/user/v1)
      ├── api.go     	接口实现
      └── router.go 	由组定义

流程

  • 程序入口(init工作)
  • API路由(拿到请求后转发,返回数据给前端,controller层)
  • API路由调用相关业务的service(接收输入,判断,过滤,组合不同的dao,return数据,业务logic层)
  • service调用相关业务的dao(dao只做对各种数据库的crud,输入参数做基本的判断和过滤)
  • dao调用相关业务的models(数据模型，一般是从数据库生成的数据结构,model层)
  • 请求 ----> controller(调度层) ----> service(业务层) ----> dao(数据访问层) ----> model

为什么要这样分层

  • 从项目的可扩展性、复杂性、分层角度
  • 为什么调度层不直接操作dao层
    • 随着业务需求的变更，某个接口代码特别多了。都是调度层里面去调用了很多个的dao层。也有了很多数据merge的各种操作，条件判断组合也很多。这个时候需要把代码进行拆分，把1000行代码拆成5个200行的函数，但是拆分后的5个人函数放在哪呢，放调度层？放dao层？
    • 引入了业务层，把这5个函数放到业务层去，在调度层去调
  • 体会高内聚低耦合，调度层不需要关注怎么操作dao，调度层只需要去调业务层。我们也专门去维护service层就行，service层中组合多个dao层

建议

  • go的项目，包的引入都全部放到当前项目的vendor下。不去依赖GOPATH目录下的包
  • go项目vendor下的包，由于维护的不到位。经常会出现包很旧导致的报错 -> 根据错误 -> 找到是哪个包 -> 删除vendor下对应的包 -> 重新下载该包

链接