一、focus项目工程目录结构
/
├── api
├── internal
│ ├── cmd
│ ├── consts
│ ├── controller
│ ├── model
│ │ └── entity
│ └── service
│ └── internal
│ ├── dao
│ └── do
├── manifest
├── resource
├── utility
├── go.mod
└── main.go
目录/文件名称说明描述
resource静态资源静态资源文件。这些文件往往可以通过 资源打包/镜像编译 的形式注入到发布文件中。
manifest交付清单包含程序编译、部署、运行、配置的文件。常见内容如下：
main.go入口文件程序入口文件。
internal内部逻辑业务逻辑存放目录。通过Golang internal特性对外部隐藏可见性。
go.mod依赖管理使用Go Module包管理的依赖描述文件。
api接口定义对外提供服务的输入/输出数据结构定义。考虑到版本管理需要，往往以api/v1...存在。
- service逻辑封装业务逻辑封装管理，特定的业务逻辑实现和封装。
- model结构模型数据结构管理模块，管理数据实体对象，以及输入与输出数据结构定义。
- entity数据模型数据模型是模型与数据集合的一对一关系，由工具维护，用户不能修改。
- docker镜像文件Docker镜像相关依赖文件，脚本文件等等。
- do领域对象用于dao数据操作中业务模型与实例模型转换，由工具维护，用户不能修改。
- deploy部署文件部署相关的文件。默认提供了Kubernetes集群化部署的Yaml模板，通过kustomize管理。
- dao数据访问数据访问对象，这是一层抽象对象，用于和底层数据库交互，仅包含最基础的 CURD 方法
- controller接口处理接收/解析用户输入参数的入口/接口层。
- consts常量定义项目所有常量定义。
- config配置管理配置文件存放目录。
- cmd入口指令命令行管理目录。可以管理维护多个命令行。
二、项目工程目录详解
2.1 业务接口 - api
业务接口包含两部分：接口定义（api）+接口实现（controller）。
api包的职责类似于三层架构设计中的UI表示层，负责接收并响应客户端的输入与输出，包括对输入参数的过滤、转换、校验，对输出数据结构的维护，并调用 service 实现业务逻辑处理。
2.2 逻辑封装 - service
service包的职责类似于三层架构设计中的BLL业务逻辑层，负责具体业务逻辑的实现以及封装。
2.3 数据访问 - dao
dao包的职责类似于三层架构中的DAL数据访问层，数据访问层负责所有的数据访问收口。
2.4 结构模型 - model
model包的职责类似于三层架构中的Model模型定义层。模型定义代码层中仅包含全局公开的数据结构定义，往往不包含方法定义。
这里需要注意的是，这里的model不仅负责维护数据实体对象（entity）结构定义，也包括所有的输入/输出数据结构定义，被api/dao/service共同引用。这样做的好处除了可以统一管理公开的数据结构定义，也可以充分对同一业务领域的数据结构进行复用，减少代码冗余。
三、项目分层流转
3.1 cmd
cmd层负责引导程序启动，显著的工作是初始化逻辑、注册路由对象、启动server监听、阻塞运行程序直至server退出。
3.2 api
上层server服务接收客户端请求，转换为api中定义的Req接收对象、执行请求参数到Req对象属性的类型转换、执行Req对象中绑定的基础校验并转交Req请求对象给controller层。
3.3 controller
controller层负责接收Req请求对象后做一些业务逻辑校验，随后调用一个或多个service实现业务逻辑，将执行结构封装为约定的Res数据结构对象返回。
3.4 model
model层中管理了所有的业务模型，service资源的Input/Output输入输出数据结构都由model层来维护。
3.5 service
service层的业务逻辑需要通过调用dao来实现数据的操作，调用dao时需要传递do数据结构对象，用于传递查询条件、输入数据。dao执行完毕后通过Entity数据模型将数据结果返回给service层。
3.6 dao
dao层通过框架的ORM抽象层组件与底层真实的数据库交互。
四、Ctx中的Request对象
我们可以通过RequestFromCtx/g.RequestFromCtx方法从ctx中获取Request对象。
使用示例：g.RequestFromCtx(ctx).Response.Writeln("Hello World!")
网友评论