MVC与三层架构之间的关系相信很多朋友都没有清晰其具体组成下面来谈谈个人的理解，或许能帮到大家更清晰的认识这俩种思想，其实之所以有这样的思想产生，目的只有一个，项目的可持续发展。
基本概念理解：
MVC：
其实一早MVC只是针对于后端开发或者前后端一体来说的：
Model（模型）：通常指的就是我们的数据模型。作用一般情况下用于封装数据。
View（视图）：通常指的就是我们的jsp或者html。作用一般就是展示数据的。通常视图是依据模型数据创建的。
Controller（控制器）：是应用程序中处理用户交互的部分。作用一般就是处理程序逻辑的。
举例webjsp分层，他们都在服务器中：
1. M：Model，模型。JavaBean
* 完成具体的业务操作，如：查询数据库，封装对象
2. V：View，视图。JSP（html在前端，这里不细讲之前的差别）
* 展示数据
3. C：Controller，控制器。Servlet
* 获取用户的输入
* 调用模型
* 将数据交给视图进行展示
三层架构：
这主要针对于项目框架的整体结构 以下会结合ssm框架来说：
表现层（springMvc struts2）：
也就是我们常说的web层。它负责接收客户端请求，向客户端响应结果，通常客户端使用http协议请求
web层，web需要接收http请求，完成http响应。
表现层包括展示层和控制层：控制层负责接收请求，展示层负责结果的展示。
表现层依赖业务层，接收到客户端请求一般会调用业务层进行业务处理，并将处理结果响应给客户端。
表现层的设计一般都使用MVC模型。（MVC是表现层的设计模型，和其他层没有关系）
业务层（spring（其实spring贯穿这个框架，放在这是为了体现其主要作用：业务逻辑））：
也就是我们常说的service层。它负责业务逻辑处理，和我们开发项目的需求息息相关。web层依赖业
务层，但是业务层不依赖web层。
业务层在业务处理时可能会依赖持久层，如果要对数据持久化需要保证事务一致性。（也就是我们说的，
事务应该放到业务层来控制）
持久层(mabatis Hibernate)：
也就是我们是常说的 dao层。负责数据持久化，包括数据层即数据库和数据访问层，数据库是对数据进
行持久化的载体，数据访问层是业务层和持久层交互的接口，业务层需要通过数据访问层将数据持久化到数据库
中。通俗的讲，持久层就是和数据库交互，对数据库表进行曾删改查的。
扩展概念:
通过上面的概念，因该对这俩种思想有了一定的了解
现在结合二者来分析：
随着程序的发展，前端的编写思想也逐渐成熟，所以有了现在的走向大前端思想，而在这条路上逐渐成熟的路上MVC思想也渐渐成熟和清晰，前端慢慢和后端走向并靠近完全分离状态，分离出来的前端有了自己的MVC：
而angularJs 等也继承了这种思想，vue在次基础进行优化（基本完全分离MVVM ）
于是现在的MVC在我的理解中分前后端
前端angular1举起来：
Model 数据（其实就是angular变量$scope.XX）
View: 数据的呈现 Html+Directive(指令)
Controller：操作数据，就是function 数据的增删改（service Controller）
后端ssm举起来：
后端许多人还会继续用mvc去分层，但我觉得用分层架构直接去描述更好：
数据访问层：dao：查询所有需要的数据
业务逻辑层：interface（service接口）： 面向接口
Service：继承本地接口，再完成web层远程调用所需要的服务
表现层： web层Controller：@reference注入接口对象，指定路径 返回结果
MVC与三层：
M（数据 ）：数据访问层 + 业务逻辑层（接口层和服务层）
C（控制 ）：表现层
V（视图 ）：表现层
说多了就会乱，简而言之：前端用mvc后端用三层架构（仅供参考，每个人都有自己的代码习惯和思想）