看完这篇，别人的开源项目结构应该能看懂了

<hr/>我为什么要写这篇

近来，和很多初学Spring或Spring Boot的小伙伴私信交换了关于项目目录结构分别和代码分层的题目。
很多小伙伴暗示网高低载下来的开源项目看不懂，项目结构和代码分层看得很蒙，不晓得应当以一个什么样的思绪去进修和吸收他人的项目。
好，明天熬夜肝了这篇文章，和大师一路来交换探讨一下，不敷之处也请小伙伴们批评斧正。
<hr/>先看看阿里是怎样约定的

我印象中，之前在看《阿里巴巴Java开辟手册》时，似乎有关于工程结构和利用分层相关的内容，因而我回翻了一下，公然有：



它这里面讲的内容大要就是：关于一个一般的企业项目里一种通用的项目结构和代码层级分别的指导定见。
按这本书上说的，一般分为以下几层：

• 开放接口层
  
• 终端显现层
  
• Web 层
  
• Service 层
  
• Manager 层
  
• DAO 层
  
• 内部接口或第三方平台
  

由于书中的篇幅关系，它这地方讲得比力笼统了，估量初学者看了还是会懵，所以接下来连系现实项目代码结构，来唠一唠具体的项目结构和代码分层。
<hr/>凡是的项目结构

首先说在前面的是：这工具并没有一套通用的标准，分歧公司大概团队的利用习惯和标准也不尽不异。

我们就以当下很是炽热的Spring Boot典型项目结构为例，建立出来的项目应当整体分为三大层：

• 项目根目录/src/main/java：放置项目Java源代码
  
• 项目根目录/src/main/resources：放置项目静态资本和设置文件
  
• 项目根目录/src/test/java：放置项目测试用例代码
  

而位于/src/main/java目录下的Java源代码的构造结构大师比力关心，这地方也只能给出一个凡是典型的结构，究竟分歧项目和团队理论纷歧样，稍许有区分，但整体放置应当差不多。而且假如是多模块的项目标话，下面的结构应当只对应其中一个模块，其他模块的代码构造也大致差不多。



各个目录具体先容：

1. |_annotation：放置项目自界说注解
2. |_aspect：放置切面代码
3. |_config：放置设置类
4. |_constant：放置常量、列举等界说
5.    |__consist：寄存常量界说
6.    |__enums：寄存列举界说
7. |_controller：放置控制器代码
8. |_filter：放置一些过滤、阻挡相关的代码
9. |_mapper：放置数据拜候层代码接口
10. |_model：放置数据模子代码
11.    |__entity：放置数据库实体工具界说
12.    |__dto：寄存数据传输工具界说
13.    |__vo：寄存显现层工具界说
14. |_service：放置具体的营业逻辑代码（接口和实现分手）
15.    |__intf：寄存营业逻辑接口界说
16.    |__impl：寄存营业逻辑现实实现
17. |_utils：放置工具类和帮助代码

复制代码

然后接下来/src/main/resources目录，里面首要寄存静态设置文件和页面静态资本等工具：

1. |_mapper：寄存mybatis的XML映照文件（假如是mybatis项目）
2. |_static：寄存网页静态资本，比以下面的js/css/img
3.    |__js：
4.    |__css：
5.    |__img：
6.    |__font：
7.    |__等等
8. |_template：寄存网页模板，比如thymeleaf/freemarker模板等
9.    |__header
10.    |__sidebar
11.    |__bottom
12.    |__XXX.html等等
13. |_application.yml       根基设置文件
14. |_application-dev.yml   开辟情况设置文件
15. |_application-test.yml  测试情况设置文件
16. |_application-prod.yml  生产情况设置文件

复制代码

固然，这地方估量有一个很多人城市纠结的关于DTO/VO/DO等数据模子界说的区分。
这在《阿里巴巴Java开辟手册》中却是做了一个所谓的严酷区分，那本书上是这样去界说的：

• DO（Data Object）：与数据库表结构逐一对应，经过DAO层向上传输数据源工具。
  
• DTO（Data Transfer Object）：数据传输工具，Service或Manager向外传输的工具。
  
• BO（Business Object）：营业工具。由Service层输出的封装营业逻辑的工具。
  
• AO（Application Object）：利用工具。在Web层与Service层之间笼统的复用工具模子，极为切近展现层，复用度不高。
  
• VO（View Object）：显现层工具，凡是是Web向模板衬着引擎层传输的工具。
  
• Query：数据查询工具，各层接收上层的查询请求。留意跨越2个参数的查询封装，制止利用Map类来传输。
  

老实讲，看到这么多工具的界说，我也是很蒙的。现实项目开辟时，我感觉没有需要决心照搬去界说这么多层工具，这样后续做工具转换工作都能烦skr人。
出于简单起见，我小我感觉，只要保证营业逻辑层Service和数据库DAO层的操纵工具严酷分别出来，确保相互不渗透，不混用，题目应当就不大。
比如在我上面举例的这个项目标代码结构中，Service层处置的工具都界说在了dto包里，而DAO层处置的工具都放在了entity包里了。
<hr/>项目结构分别总结

假如从一个用户拜候一个网站的情况来看，对应着上面的项目代码结构来分析，可以贯串全部代码分层：



对应代码目录的流转逻辑就是：



我想，应当看得比力清楚了吧。
所以，今后每当我们拿到一个新的项目得手时，只要依照这个思绪去看他人项目标代码，应当根基都是能理得顺的。
<hr/>一些留意事项

1、Contorller层参数传递倡议不要利用HashMap，倡议利用数据模子界说
2、Controller层里可以做参数校验、异常抛出等操纵，但倡议不要放太多营业逻辑，营业逻辑只管放到Service层代码中去做
3、Service层做现实营业逻辑，可以依照功用模块做好界说和区分，相互可以挪用
4、功用模块Service之间援用时，倡议不要渗透到DAO层（大概mapper层），基于Service层停止挪用和复用比力公道
5、营业逻辑层Service和数据库DAO层的操纵工具不要混用。Controller层的数据工具不要间接渗透到DAO层（大概mapper层）；同理数据表实体工具Entity也不要间接传到Controller层停止输出或展现。
<hr/>

确切干货

期待更多干货  [爱心]

羊哥的文章也是干货满满的[赞]
在b站上就经常看羊哥的视屏了

很清楚，感谢

不错！
现在好多项目是分模块（module）来开辟的，感受与这个逻辑大同小异，只是将分层的package放到对应的 module下了。大神有空的话也请分享一下经历。

你供给的几个图太棒了，看了好多文章，看你写文章才有了比力清楚的思绪[赞]