近期和读者交流聊到项目规范，借着这个机会我们不妨聊聊主流Java项目是如何进行分层的。
Hi，我是 sharkChili ，是个不断在硬核技术上作死的 java coder ，是 CSDN的博客专家 ，也是开源项目 Java Guide 的维护者之一，熟悉 Java 也会一点 Go ，偶尔也会在 C源码 边缘徘徊。写过很多有意思的技术博客，也还在研究并输出技术的路上，希望我的文章对你有帮助，非常欢迎你关注我的公众号： 写代码的SharkChili 。
因为近期收到很多读者的私信，所以也专门创建了一个交流群，感兴趣的读者可以通过上方的公众号获取笔者的联系方式完成好友添加，点击备注 “加群” 即可和笔者和笔者的朋友们进行深入交流。
大部分人都认为项目的分层无非是、、这3层，尽管这种规约在项目几乎是默认的，有时却因为团队沟通或者需求快速迭代，导致项目中会出现以下几种情况:
- 接口逻辑全写在，仅做透传持久层的透传。
- 层对象直接返回到层，直接无视层。
- 层对象不做任何转换直接一路传到层。
就笔者的个人经验而言，这种情况大部分出现在有一定开发经验老码农身上，而新人接手项目时没有经过沟通，直接照猫画虎，于是这种恶习便一路传下来，进而出现如下几个问题:
- 代码不易扩展。
- 分层效果让团队难以接受。
- 各层职责边界不清晰，难以复用。
按照阿里的规约，对应的项目会按照如下规范进行分层：
- 开放接口层：封装service方法对外暴露为接口或者通过封装成接口进行网关安全控制或者流量控制等。
- 终端显示层：各个模板渲染并显示的层级，我们可直接通俗的理解为前端渲染的页面。
- 层：主要对访问控制进行转发、参数校验、逻辑调用等，也就是我们常说的controller层。
- ：真正逻辑处理的层级，严格来说一个就对应一个，之所以用逻辑都封装在service是为了方便后续封装接口时，可以通过直接调用完成扩展。
- ：通用的业务处理层级，常用于第三方平台能力封装，或者中间件、缓存方案通用处理、对多进行逻辑组合，总的来说manager层提供各种原子服务接口，而service层对这些原子接口进行逻辑编排。
- 层：持久层，也就是直接和数据库交互的一层。
对应的我们给出分层的图解：
明确分层后，我们也需要针对各层提出领域模型规约：
- ：即持久层对象，所有的数据库查询后转换为Java映射的对象都以结尾，该层与数据表一一对应。
- ：持久层完成查询之后得到的，层或者层就需要将其转换为对外传输。
- ：层返回给视图层进行渲染的对象。
- ：入参对象，如果超过两个则需要封装，禁止使用，这是强制要求。
很明显，这种做法虽然保证了层级分明，但是为了所谓的规范却耗费开发大量精力进行对象转化，明显降低了开发的效率。
所以我们对此做一个折中，得到下面这样一个开发规约图解，其交互过程为：
- 入参一律使用，进行参数校验之后，由于或者将传给或者。
- 和在业务处理时可直接操作层的对象进行逻辑处理。
- 和完成逻辑后最终封装成返回给上层也就是或者层。
由此我们既实现了规范的的分层又保证了开发的效率。
基于上述的分层理论，笔者给出一个个人比较常用的项目结构，整体结构树如下所示，读者可参考自行调整使用：
以上便是笔者对于项目分层规范的总结，希望对你有帮助。
我是 sharkchili ，CSDN Java 领域博客专家，开源项目—JavaGuide contributor，我想写一些有意思的东西，希望对你有帮助，如果你想实时收到我写的硬核的文章也欢迎你关注我的公众号： 写代码的SharkChili 。
因为近期收到很多读者的私信，所以也专门创建了一个交流群，感兴趣的读者可以通过上方的公众号获取笔者的联系方式完成好友添加，点击备注 “加群” 即可和笔者和笔者的朋友们进行深入交流。
同事问我代码结构中 Manager层是干什么的:https://juejin.cn/post/
版权声明：
本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。
本文网址：https://www.bianchenghao6.com/java-jiao-cheng/16943.html