MVC模式和三层架构到底有没有关系？

1. MVC 模式

为了便于管理繁杂的代码，以及降低代码的耦合性，于是衍生出了MVC模式，可以使开发者思路更加清晰，且代码更加利于维护。

Web MVC中的M(模型)-V(视图)-C(控制器)概念和标准MVC概念一样，Web MVC标准架构如下图所示：

M(Model) 模型 : 应用程序的核心功能，管理这个模块中用的数据和值，包含Dao层和Bean层

V(View )视图: 视图提供模型的展示，管理模型如何显示给用户，它是应用程序的外观，一般指JSP或HTML前端页面

C(Controller)控制器: 对用户的输入做出反应，管理用户和视图的交互，是连接模型和视图的枢纽。包含Servlet层和Service层

MVC用于将web（UI）层进行职责解耦

2. 三层架构

通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了「高内聚，低耦合」的思想。

• 表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。 jsp/html
• 业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。
  servlet，service
• 数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。dao

表现层实现的代表作品是Struts，springmvc框架，

业务层实现的代表作品是Spring

持久层实现的代表作品是Hibernate,mybatis。

层就相当于一个黑盒子，我们不用知道它内部怎么实现，只需要知道如何去调用它就行了。每层只与上下相邻的两层打交道。当一层内部由于技术变迁发生变化时，只要接口不变，其他层不用做任何改变。分层之后灵活性提高，也便于团队分工开发。

3. 三层架构和MVC的区别与联系

MVC是 Model-View-Controller，严格说这三个加起来以后才是三层架构中的UI层，也就是说，MVC把三层架构中的UI层再度进行了分化，分成了控制器、视图、实体三个部分，控制器完成页面逻辑，通过实体来与界面层完成通话；而C层直接与三层中的BLL进行对话。

MVC可以是三层中的一个表现层框架，属于表现层。三层和mvc可以共存。

三层是基于业务逻辑来分的，而MVC是基于页面来分的。

MVC主要用于表现层，三层主要用于体系架构，三层一般是表现层、中间层、数据层，其中表现层又可以分成M、V、C，(Model View Controller)模型－视图－控制器

MVC是表现模式（Presentation Pattern），三层架构是典型的架构模式（Architecture Pattern）

三层架构的分层模式是典型的上下关系，上层依赖于下层。但MVC作为表现模式是不存在上下关系的，而是相互协作关系。即使将MVC当作架构模式，也不是分层模式。

MVC和三层架构基本没有可比性，是应用于不同领域的技术。

https://www.cnblogs.com/zhhh/archive/2011/06/10/2077519.html，这篇文章对MVC和三层的关系是这样说的：

三层是三层，MVC是MVC，它们毫无关系的。

三层是从整个应用程序架构的角度来分的三层（如果程序需要，还可以分多层）。

三层是为了解决整个应用程序中各个业务操作过程中不同阶段的代码封装的问题，为了使程序员更加专注的处理某阶段的业务逻辑。

比如将数据库操作代码封装到一层中，提供一些方法根据参数直接返回用户需要的相应数据，这样在处理具体的业务逻辑的时候，就不用关心数据的存储问题了。

MVC是在应用程序（BS结构）的视图层划分出来的不同功能的几个模块。

MVC主要是为了解决应用程序用户界面的样式替换问题，把展示数据的 HTML 页面尽可能的和业务代码分离。MVC把纯净的界面展示逻辑（用户界面）独立到一些文件中（Views），把一些和用户交互的程序逻辑（Controller）单独放在一些文件中，在 Views 和 Controller 中传递数据使用一些专门封装数据的实体对象，这些对象，统称为Models。

之所以说MVC和三层毫无关系，是因为它们二者使用范围不同：三层可以应用于任何语言、任何技术的应用程序；而MVC只是为了解决BS应用程序视图层各部分的耦合关系。它们互不冲突，可以同时存在，也可根据情况使用其中一种。