GoFrame工程目录设计介绍

本文主要是介绍GoFrame工程目录设计介绍，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

GoFrame框架针对业务项目的目录设计，主体的思想来源于三层架构，但在具体实现中，对其进行了一定的改进和细化使其更符合工程实践和时代进步。

一.工程目录结构

GoFrame业务项目基本目录结构如下：
在这里插入图片描述

二.目录结构解释

在这里插入图片描述
对外接口

对外接口包含两部分：接口定义（api）+接口实现（controller）。

服务接口的职责类似于三层架构设计中的UI表示层，负责接收并响应客户端的输入与输出，包括对输入参数的过滤、转换、校验，对输出数据结构的维护，并调用 service 实现业务逻辑处理。

接口定义 - api

api包用于与客户端约定的数据结构输入输出定义，往往与具体的业务场景强绑定。

接口实现 - controller

controller用于接收api的输入，调用内部的一个或多个service包实现业务场景，组织service的结果构造为api的输出数据结构。

业务实现

业务实现包含两部分：业务接口（service）+业务封装（logic）。

业务实现的职责类似于三层架构设计中的BLL业务逻辑层，负责具体业务逻辑的实现以及封装。

在后续的章节介绍中，我们会将业务实现统一称作service，大家注意它其实包含两部分即可。

业务接口 - service

service包用于解耦业务模块之间的调用。业务模块之间往往不会直接调用对应的业务模块资源来实现业务逻辑，而是通过调用service接口。service层只有接口定义，具体的接口实现注入在各个业务模块中。

业务封装 - logic

logic包负责具体业务逻辑的实现以及封装。项目中各个层级代码不会直接调用logic层的业务模块，而是通过service接口层来调用。

结构模型

model包的职责类似于三层架构中的Model模型定义层。模型定义代码层中仅包含全局公开的数据结构定义，往往不包含方法定义。

这里需要注意的是，这里的model不仅负责维护数据实体对象（entity）结构定义，也包括所有的输入/输出数据结构定义，被api/dao/service共同引用。这样做的好处除了可以统一管理公开的数据结构定义，也可以充分对同一业务领域的数据结构进行复用，减少代码冗余。

数据模型 - entity

与数据集合绑定的程序数据结构定义，通常和数据表一一对应。

业务模型 - model

与业务相关的通用数据结构定义，其中包含大部分的方法输入输出定义。

数据访问 - dao

dao包的职责类似于三层架构中的DAL数据访问层，数据访问层负责所有的数据访问收口。

三.请求的分层流转

在这里插入图片描述

cmd
cmd层负责引导程序启动，显著的工作是初始化逻辑、注册路由对象、启动server监听、阻塞运行程序直至server退出。
api
上层server服务接收客户端请求，转换为api中定义的Req接收对象、执行请求参数到Req对象属性的类型转换、执行Req对象中绑定的基础校验并转交Req请求对象给controller层。
controller
controller层负责接收Req请求对象后做一些业务逻辑校验，随后调用一个或多个service实现业务逻辑，将执行结构封装为约定的Res数据结构对象返回。
model
model层中管理了所有的业务模型，service资源的Input/Output输入输出数据结构都由model层来维护。
service
service是接口层，用于解耦业务模块，service没有具体的业务逻辑实现，具体的业务实现是依靠logic层注入的。
logic
logic层的业务逻辑需要通过调用dao来实现数据的操作，调用dao时需要传递do数据结构对象，用于传递查询条件、输入数据。dao执行完毕后通过Entity数据模型将数据结果返回给service层。
dao
dao层通过框架的ORM抽象层组件与底层真实的数据库交互。