应用分层 类似与公司的组织架构
公司初创阶段，一个人身兼数职，既做财务，又做人事，还做行政随着公司逐渐壮大，会把岗位进行细分，划分为财务部门，人事部门，行政部门等。各个部门内部还会进行细分项目的开发也是如此，最开始功能简单的时候，我们前后端放在一起开发，随着项目功能的复杂，我们分为前端和后端不同的团队，甚至更细粒度的团队。后端开发也会根据功能再进行细分，MVC 就是其中的一种拆分方式但是随着后端人员不再设计前端，后端开发又有了新的分层方式阿里开发手册中，关于工程结构部分，定义了常见工程的应用分层结构
image.png是什么那么什么是应用分层呢？
应用分层是一种软件开发设计思想，它将应用程序分成 N 个层次，这 N 个层次分别负责各自的职责，多个层次之间协同提供完整的功能，根据项目的复杂度，把项目分成三层，四层或者更多
常见的 MVC 设计模式，就是应用分层的一种具体体现
为什么要分层在最开始的时候，为了让项目快速上线，我们通常是不考虑分层的，但是随着业务越来越复杂，大量的代码混在一起，会出现逻辑不清器、模块项目依赖、各模块相互依赖、代码扩展性差、改动一处就牵一动而发全身等问题。
所以学习对项目进行分层就是我们必须要的了
如何分层（三层架构）我们上一节中学习的“MVC”，就是把整体的系统分成了 Model（模型），View（视图）和 Controller（控制器）三个层次，也就是将用户视图和业务处理隔离开，并且通过控制器连接起来，很好地实现了表现和逻辑的解耦，是一种标准的软件分层架构
image.png|496
目前现在更主流的开发方式是“前后端分离”的方式，后端开发工程师不再需要关注前端的实现，所以对于 Java 后端开发者，又有了一种新的分层架构：把整体架构分为表现层、业务逻辑层和数据层。这种分层方式也称为“三层架构”
表现层：就是展示数据结果和接收用户指令的，是最靠近用户的一层业务逻辑层：负责处理业务逻辑，里面有复杂业务的具体实现数据层：负责存储和管理与应用程序相关的数据可以看到，我们前面写的代码，并不符合这种设计思想，而是所有代码堆砌在一起
image.png|428按照上面的层次划分，Spring MVC 站在后端开发人员的角度上，也进行了支持，把上面的代码划分为三个部分：
请求处理、响应数据：负责，接收页面的请求，给页面响应数据逻辑处理：负责业务逻辑处理的代码数据访问：负责业务数据的维护操作，包括增、删、改、查等操作这三个部分，在 Spring 的实现中，均有体现：
image.png|527Controller：控制层。接收前端发送的请求，对请求进行处理，并响应数据Service：业务逻辑层。处理具体的业务逻辑Dao：数据访问层，也称为持久层。负责数据访问操作，包括数据的增、删、改、查MVC 和三层架构的区别和联系关于二者的关系，一直存在不同的观点。有人认为三层架构是 MVC 模式的一种实现，也有人认为 MVC 是三层架构的替代方案，等等各种说法都有。根本原因是大家站在不同的角度来看待这个问题
从概念上来讲，二者都是软件工程领域中的架构模式
MVC 架构模式由三部分组成，分别是：模型（Model），视图（View）和控制器（Controller）三层架构将业务应用划分为：表现层，业务逻辑层，数据访问层 image.pngMVC 中，视图和控制器合起来对应三层架构中的表现层，模型对应三层架构中的业务逻辑层，数据层，以及实体类二者其实是从不同角度对软件工程进行了抽象
MVC 模式强调数据和视图分离，将数据展示和数据处理分开，通过控制器对两者进行组合三层架构强调不同维度数据处理的高内聚合低耦合，将交互界面，业务处理和数据库操作的逻辑分开
角度不同也就谈不上互相替代了，在日常开发的可以经常看到两种共存情况，比如我们设计模型层的时候往往也会拆分出业务逻辑层（Service 层）和数据访问层（Dao 层）但是二者的目的都是相同的，都是“解耦，分层，代码复用“
高内聚低耦合高内聚是指：一个模块中各个元素之间的联系的紧密程度，如果各个元素（语句、程序段）之间的联系程度越高，即“高内聚”低耦合指的是：软件中各个层、模块之间的依赖关联程序越低越好。修改一处代码，其他模块的代码改动越少越好image.png|414高内聚低耦合矛盾吗？
不矛盾，高内聚指的是一个模块中各个元素之间的联系的紧密程度，低耦合指的是各个模块之间的紧密程度
这就好比一个企业，包含很多部门，各个部门之间的关联关系要尽可能的小，一个部门发生问题，要尽可能降低对其他部门的影响，就是耦合。但是部门内部员工关系要尽量紧密，遇到问题一起解决，克服，这就叫内聚
比如邻里邻居，楼上漏水，楼下遭殃，就是耦合。家庭一个成员生病，其他成员帮忙照顾，就叫内聚。一个家庭内部的关系越紧密越好，一个家庭尽可能少的影响另一个家庭，就是低耦合
分层的好处降低层与层之间的依赖，结构更加的明确，利于各层逻辑的复用开发人员可以只关注整个结构中的其中某一层，极大地降低了维护成本和维护时间可以很容易的用新的实现来替换原有层次的实现有利于标准化企业规范类名使用大驼峰风格，但一下情形例外：DO / BO / DTO / VO / `AO方法名、参数名、成员变量、局部变量统一使用小驼峰风格包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词 常见命名风格介绍
大驼峰：所有单词首字母都需要大写，又叫帕斯卡命名法，比如：UserController小驼峰：除了第一个单词，其他单词首字母大写，比如：userController蛇形：用下划线(_)，作用单词间的分隔符，一般小写，又叫下划线命名法，比如：user_controller串行：用短横线(-) 作用单词间的分隔符，又叫脊柱命名法，比如：user-controller