5、MVC与三层架构的区别：MVC与三层架构（表现层、业务逻辑层、数据访问层）的对比分析，以及它们在实际项目中的结合使用。
聊到架构设计，有两个概念经常被拿出来比较——MVC 和三层架构。很多新手容易把它们搞混，甚至觉得「这不就是一回事吗？」。嗯，我刚开始带项目时也犯过这个错，直到有一次在代码评审会上被老前辈问住：「你管 Controller 叫表现层，那 View 算什么？」
说白了，它们俩虽然长得像，但关注的点完全不同。今天我就把这两个东西掰开揉碎了讲清楚。
5.1 三层架构：纵向切分，关注职责分离
三层架构是一种纵向分层的思想。它把整个系统从上到下切成三块：
- 表现层（UI层）：负责和用户打交道。展示数据、接收输入。
- 业务逻辑层（BLL）：负责核心业务规则。比如「订单金额满100减20」这种逻辑。
- 数据访问层（DAL）：负责和数据库打交道。增删改查，封装 SQL。
每一层只依赖它的下一层。表现层调用业务层，业务层调用数据层。反过来不行。这种设计的好处是——替换某一层不影响其他层。比如我把数据库从 MySQL 换成 PostgreSQL，只需要改数据访问层，业务逻辑完全不用动。
核心要点：三层架构解决的是「技术栈的纵向分层」问题。它关注的是「代码该放在哪一层」。
5.2 MVC：横向切分，关注交互模式
MVC 是一种横向切分的模式。它把一个请求的处理过程拆成三个角色：
- Model（模型）：数据和业务规则。注意，这里的 Model 包含了三层架构中「业务逻辑层 + 数据访问层」的职责。
- View（视图）：用户界面。负责渲染数据。
- Controller（控制器）：接收用户输入，调用 Model 处理，然后选择 View 展示结果。
MVC 的核心是事件驱动。用户点击按钮 -> Controller 收到请求 -> 更新 Model -> Model 通知 View 刷新。这是一个闭环。
我个人的理解：三层架构是「物理分层」，MVC 是「逻辑分工」。一个管代码放哪，一个管流程怎么走。
5.3 一张图看懂区别与联系
下面这张 SVG 图是我自己画的，把两者的关系梳理清楚了。你看完应该就能明白它们是怎么配合的。
5.4 核心区别对比表
我整理了一个表格，把关键差异列出来。这样你一眼就能看出区别。
| 对比维度 | 三层架构 | MVC |
|---|---|---|
| 关注点 | 代码职责的纵向分层 | 请求处理的横向分工 |
| 分层方式 | 表现层 / 业务层 / 数据层 | Model / View / Controller |
| 通信方式 | 上层调用下层，单向依赖 | Controller 调度 Model 和 View，双向通知 |
| 典型场景 | 企业级应用、桌面软件 | Web 应用、移动端 App |
| 替换成本 | 替换一层不影响其他层 | 替换 View 不影响 Model |
| 常见误区 | 把 Controller 当成表现层 | 把 Model 当成纯数据对象 |
5.5 实际项目中的结合使用
在实际项目中，MVC 和三层架构从来不是二选一。它们可以共存，而且配合得很好。我参与过的几个大型电商项目，都是这么干的：
- 用三层架构做整体分层：项目结构按「表现层 - 业务层 - 数据层」来组织包名。
- 在表现层内部用 MVC：表现层再拆成 Controller、View、Model（这里的 Model 是 ViewModel，不是业务 Model）。
- Controller 只做调度：Controller 收到请求后，调用业务层的 Service 方法，然后把结果封装成 ViewModel 传给 View。
举个例子，一个典型的 Spring MVC 项目结构是这样的：
com.example.project
├── controller # MVC 的 Controller
│ └── OrderController.java
├── service # 业务逻辑层（三层架构中的 BLL）
│ └── OrderService.java
├── dao # 数据访问层（三层架构中的 DAL）
│ └── OrderDao.java
├── model # 业务模型（三层架构中的 Model）
│ └── Order.java
└── view # MVC 的 View（JSP / Thymeleaf 模板）
└── orderList.html
我曾经踩过的坑：刚开始用 Spring MVC 时，我把业务逻辑直接写在 Controller 里。结果项目一复杂，Controller 变得又臭又长，测试也没法写。后来才明白——Controller 只负责「接请求、调服务、返回视图」，业务逻辑必须下沉到 Service 层。
5.6 避坑指南：常见误区
这里我总结几个新手容易犯的错误，你注意避开：
- 误区一：把 Controller 当成表现层。Controller 是 MVC 的一部分，不是三层架构的表现层。表现层应该是 View + Controller 的组合。
- 误区二：在 View 里写业务逻辑。JSP 里写 SQL？我见过。结果维护成本高得吓人。记住，View 只负责展示。
- 误区三：Model 里塞太多东西。有些同学把数据库查询、业务计算、数据校验全塞进 Model 类里。Model 应该保持轻量，只包含数据和简单的业务方法。
- 误区四：忽略分层之间的接口。层与层之间一定要定义清晰的接口。我曾经接手过一个项目，Service 层直接 new Dao()，耦合度极高，改个数据库连接池都要改十几个文件。
我的建议：刚开始做项目时，先按三层架构把包结构搭好。然后在表现层内部引入 MVC。这样既保证了代码的层次清晰，又利用了 MVC 的交互优势。说白了，就是「大三层，小 MVC」。
5.7 总结
MVC 和三层架构不是对手，而是搭档。三层架构帮你把代码分到不同的「楼层」，MVC 帮你把每一层内部的「工作流程」理顺。理解了这个，你写出来的代码就会更清晰、更容易维护。
嗯，我记得有一次重构一个老项目，就是按照这个思路来的。先把代码按三层架构重新组织，然后在表现层引入 MVC。重构完之后，团队里新来的同事看代码都说「舒服多了」。这就是架构的魅力。
一句话记住：三层架构是「骨架」，MVC 是「肌肉」。骨架撑起结构，肌肉驱动动作。两者结合，项目才能跑得稳、跑得快。
公众号:蓝海资料掘金营，微信deep3321