一件事，要知其然往往很简单，要知其所以然通常不是那么容易，就如最近重新巩固spring的过程中，就觉得还有许多问题其实并不是十分明了。
屈指一算，手头上做过的正式项目也有了四五六七个了，不管用的数据库和其他一些细节上的技术如何，总的来说大的框架结构都是差不多的。
说白了，也就是mvc和三层结构。
而mvc和三层结构究竟是什么关系，我曾在面试的过程中被人问过几次，也曾仔细的想过、查过这个问题，但是直到此时，我也还是不能完全确定。
只不过随着时间的积累，随着技术的沉淀，随着视野的拓宽，我大体上认同了两种说法，不管别人怎么看，我个人是觉得两种说法都有道理，欢迎对这个问题有不同看法的朋友一起讨论。
三层结构是什么，是展现层、应用层、数据访问层，这个基本上是没有太大的异议的，两种看法的来源基本上都是来自对于mvc的理解。
对于java web应用来说，不管是B/S还是C/S，大体上都可以分成服务端和客户端两部分，只不过B/S的客户端就是公用的浏览器。
基于这种大的架构，有一种对于mvc的说法就是：
m是model，也就是和数据库相关的那些，比如实体类和dao、mapper.xml等，对应着三层结构的数据访问层；
v是view，也就是前台的页面或者说是客户端展示给用户看的东西，也就是展现层；
而c就是controller以及service等具体的业务逻辑，对应着三层结构的应用层。
这种说法我觉得应该是为了对应而对应，就是要把mvc和三层结构的关系一一对应起来，因此也差不多就是一个对应一个。
或许是经验还不够多的缘故，或许本来就是这样子，反正我是觉得这种说法正确，或者更确切的说，这是大的mvc。
那么还有一种说法可能就不是像上边这样一一对应了，大体上的说法是这样的：
我们通常所说的mvc实际上只是对应了三层结构中的展现层，也就是view而已，然后v是客户端，m是实体，c是controller。
至于三层结构中的应用层和数据访问层则是分别对应了后台代码中的service和dao。
而对于这种说法，为什么我觉得有道理呢？是因为按照这种描述，就是和前台展示直接相关的东西都放在展现层。
*比如controller要直接和url打交道，而很多时候返回给客户端的数据也会封装成对象的形式，经常就是model；也就是说不管是controller还是model，都实打实和用户看得到的部分相关，就划为了展现层。
只不过在某些时候，就比如我们现在的项目中，为了进一步的实现松耦合，我们会创建一个command类，类似于实体model，然后用model操作数据库，用command和前台打交道，道理是一样的。
而在另一方面，我们现在项目前端使用的技术是angular js，这项技术现在也说实现了前台的mvc，有controller、service，还有数据层。
因此在这种情况下，我个人就觉得，mvc本就是一个概念，重要的是一种理解，它本身的作用只是为了实现松耦合，而不是为了mvc而mvc，未必一定要有一个唯一的答案！
欢迎有其他理解的朋友留言交流！
以下是我觉得比较好的其他理解：
来自百度百科的说法，是否是标准？
MVC（模型Model-视图View-控制器Controller）是一种架构模式，可以用它来创建在域对象和UI表示层对象之间的区分。
同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的地方在于其他的两个层。
在三层架构中没有定义Controller的概念。这是最不同的地方。而MVC也没有把业务的逻辑访问看成两个层，这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model，但是三层架构中Model的概念与MVC中Model的概念是不一样的，“三层”中典型的Model层是以实体类构成的，而MVC里，则是由业务逻辑与访问数据组成的。
MVC和三层架构有什么区别就是MVC是最流行的三层架构中的一种框架，就是模型-视图-控制器三者分离。
MVC模式（Model–view–controller）是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。
MVC模式最早由Trygve Reenskaug在1978年提出[1] ，是施乐帕罗奥多研究中心（Xerox
PARC）在20世纪80年代为程序语言Smalltalk发明的一种软件架构。MVC模式的目的是实现一种动态的程式设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。除此之外，此模式通过对复杂度的简化，使程序结构更加直观。软件系统通过对自身基本部分分离的同时也赋予了各个基本部分应有的功能。专业人员可以通过自身的专长分组：
控制器（Controller）- 负责转发请求，对请求进行处理。 视图（View） - 界面设计人员进行图形界面设计。 模型（Model）
- 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
无意中看到这个问题，我前段时间也想了很久，今天看到有点感触，不知道您怎么看，我一直其实有疑惑的(一个刚参加工作的新人)对于mvc的三层架构，设计理念是为了实现高内聚低耦合，您说得第一种三层结构，我觉得其实并没有达到这个低耦合的效果，因为在应用层处理业务时，并没有将真正的业务逻辑和数据库逻辑分离开来，仅仅将视图和逻辑分离开了，并没有达到低耦合的效果，个人这并不是真正的MVC。
个人的理解，mvc应该分为5层。
1.视图层(html/jsp/)等用户能看得到的信息，数据信息的开始和结束。
2.控制层(servlet/action),控制层不处理任何业务(包括业务逻辑和数据库逻辑)，只为控制流程，实现跳转功能，只调用service层的结果实现跳转功能，控制层的逻辑更偏向视图层，为视图层提供服务。
3.服务层(service)：专门处理业务逻辑，是控制层和DAO的中间过渡层，根据DAO层的返回结果的不同，处理不同的业务逻辑，并将结果向上返回给控制层。
4.DAO层：专门处理各种数据库逻辑，包括对数据库的CRUD，存储过程/函数各种操作，提供访问数据库的接口，DAO层更偏向于model。
5.数据模型层：专门封装数据原始模型(javabean/DTO)，本身不提供任何对数据库的操作，只提供接口供DAO层调用数据。 从上到下依次为视图层，控制层，服务层，DAO层，数据模型层。 个人理解，新人刚入门，有错误的地方希望指出共同学习。
我对来看日出的回复如下：
实际上，我个人现在的观点是，我觉得我说的两种都有道理，而你说的这一种也有道理，只看出发点是什么，能不能说通。
你的这种说法，应该是实际开发时的代码结构，后端通常有model、dao、service、controller，但是现在的前端，就比如我们用的angular js，实际上也分成了数据模型层、servie层、controller层、html展示层。
因此，我的理解是，网上常见的mvc解释应该是针对之前整个系统架构比较简单的情况，而现在前后端各种架构和技术都复杂起来了，可能便不能再这样简单的对应。
也就是说，我说的两种实际上对于现在的情况可能都不对了。
随着工作时间的增长，我对这个问题的看法一直在变，或许就是那句“看山是山，然后看山不是山，然后看山是山”，理解性的东西，本来就会随着个人的阅历增长而变化，今天觉得对的可能明天就觉得错了。
所以，归根结底，我觉得可以回到主题：我觉得对错不重要，重要的是能不能说通，是不是自己的理解，对也好，错也罢，能说的有理有据就够了，因为理解会变。