springboot 工程结构

项目的工程结构理论上来说并没有什么强制要求，我们可以把所有的业务逻辑写在接口方法中，这并不会影响我们项目的运行。

对于我而言，规范好自己的工程结构，对自己对别人都是很好的，不同结构各司其职，互不越界是我编写项目的规范之一。

---

下图是整合了阿里孤尽老师的《JAVA开发手册》中所提及的工程结构，我也是针对了该工程结构反思了自己先前的一些项目写法。

对于springboot项目而言，一个完整的请求大致会按顺序经过以下流程

1. Filter与Interceptor 这两者的功能接近，但具体实现技术不同。通常会在该层进行简单的url处理或鉴权

2. controllerAdvice 这是spring3.2提供的新注解，当前大多用于搭配@ExceptionHandler进行全局异常处理

3. aspect 此处的aspect仅针对处理controller的aspect 通常我们会使用切面来实现一些非主业务的功能，例如日志、异常处理、权限控制等 但我个人而言，我并不喜欢在aspect进行权限控制，如下图所示，未授权的调用理应无法通过拦截器，而一旦通过拦截器，便默认拥有当次请求的操作权限。

4. controller 通常所说的请求处理层，对请求的业务操作下放到具体的service处理，而自身仅仅做的是一些不复用的功能，例如参数校验。 尽可能别将业务逻辑直接写在controller层。

5. service 完成具体的业务逻辑，实现与DAO或Mapper的数据交互。 个人而言，我觉得service层不进行参数校验这类不属于业务逻辑的工作。

6. DAO或Mapper 与数据库直接交互

springboot的核心理念：约定优于配置。

所以项目结构的合理设计也是尤为重要，当然也要因地制宜，主要还是要合理、舒服即可