1、简介
MVC是一种架构设计模式，是一种设计理念。是为了达到分层设计的目的，从而使代码解耦，便于维护和代码的复用。MVC是3个单词的缩写，全称：Model-View-Controller（模型-视图-控制器）。
Model：
Model在MVC中扮演着功能掌控者的角色，属于底层，它处理业务逻辑和数据模型，例如User selectUser（）；这个方法和它调用之后返回的Bean都是属于Model的。至于以何种方式把User传递到前台（例如以Bean的方式传递，使用JSP标签进行处理；或者使用Json格式进行传递，在前台使用JS语言进行处理），可以自由选择。
View：
View在MVC中扮演这展示者的角色，属于上层，它展示从底层提取出来的数据（如以表格，图表等方式），在Jsp中是以Jsp标签进行展示，在其它前台框架中是用Json格式进行数据的处理（在Spring中@controller返回的是JavaBean，@RESTcontroller返回的是Json格式的数据）。
Controller：
Controller在MVC中扮演的是路由控制的角色，属于中间层，它处理用户通过前端发送过来的请求（当然其它MV*模式可能不通过Controller直接向Model发送请求），并调用底层中的对应的方法进行数据的请求，然后将数据发送出去。
2、实例
MVC 主要的框架有 Spring Struts ZF .NET
以SpringMVC为例来解释下MVC在spring的工作流程中如何体现的
springMVC是一个MVC的开源框架，springMVC=struts2+spring，springMVC就相当于是Struts2加上sring的整合，但是这里有一个疑惑就是，springMVC和spring是什么样的关系呢？这个在百度百科上有一个很好的解释：意思是说，springMVC是spring的一个后续产品，其实就是spring在原有基础上，又提供了web应用的MVC模块，可以简单的把springMVC理解为是spring的一个模块（类似AOP，IOC这样的模块），网络上经常会说springMVC和spring无缝集成，其实springMVC就是spring的一个子模块，所以根本不需要同spring进行整合。
这张图中将前端的视图用jsp来代替，Dao是MVC外的另一个层数据持久层，主要进行对数据库的操作。
SpringMVC的工作流程就是
第一步:用户发起请求到前端控制器（DispatcherServlet）
第二步：前端控制器请求处理器映射器（HandlerMappering）去查找处理器（Handle）：通过xml配置或者注解进行查找
第三步：找到以后处理器映射器（HandlerMappering）像前端控制器返回执行链（HandlerExecutionChain）
第四步：前端控制器（DispatcherServlet）调用处理器适配器（HandlerAdapter）去执行处理器（Handler）
第五步：处理器适配器去执行Handler
第六步：Handler执行完给处理器适配器返回ModelAndView
第七步：处理器适配器向前端控制器返回ModelAndView
第八步：前端控制器请求视图解析器（ViewResolver）去进行视图解析
第九步：视图解析器像前端控制器返回View
第十步：前端控制器对视图进行渲染
第十一步：前端控制器向用户响应结果
例如①，小时候玩的那种卡带式游戏机，Control是主机，一般来说我买一个主机就行了，只要他不坏，他就能一直让我玩这一类的游戏。View则是电视机和游戏手柄，电视机可以独立工作，他不管输入的是电视信号、影碟机信号还是游戏机信号，他只管显示，而且他决定了我们看到的效果是怎么样的，如果我想要个尺寸更大的或者彩色的显示效果，我只需要买个相应的电视机就行了，手柄也是可以换的，遥杆还是带震动的。Model则是游戏卡带，他决定了我玩的是什么游戏，是魂斗罗还是超级玛莉，而且游戏机主机和电视机生产厂家永远也不知道在上面有可能会运行什么样的游戏。卡带中可能会有游戏代码和存储单元，都根据游戏的需要而设计。
例如②，一个采用比例表示的用于政治选举的一个简单信息系统，它提供了一个输入数据的电子数据表和表示当前结果的几种图标。用户可以通过图形接口与系统交互。所有信息显示必须立即反应出选举数据的变化。（引用自《面向模式的软件体系结构-卷1 模式系统》）
即，一旦模型的数据发生了变化，模型要通报所有的视图。
3、存在的问题
因为在PHP还不支持面向对象之前，是过程化的方式来创建的，它们将 Model View Controller 三层的代码混在一起，十分混乱。所以它解决的问题有：维护难，开发速度慢，二次开发难度高，工作量大，代码复用，耦合度高，系统不灵活。
4、 MVC架构的优缺点
优点：
耦合性低
视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。
重用性高
MVC模式允许使用各种不同样式的视图来访问同一个服务器端的代码，因为多个视图能共享一个模型，它包括任何WEB（HTTP）浏览器或者无线浏览器（wap），比如，用户可以通过电脑也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面使用。
生命周期成本低
MVC使开发和维护用户接口的技术含量降低。
部署快
使用MVC模式使开发时间得到相当大的缩减，它使程序员（Java开发人员）集中精力于业务逻辑，界面程序员（HTML和JSP开发人员）集中精力于表现形式上。
可维护性高
分离视图层和业务逻辑层也使得WEB应用更易于维护和修改。
有利软件工程化管理
由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。控制器也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。
缺点：
没有明确的定义
完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。
不适合小型，中等规模的应用程序
花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。
增加系统结构和实现的复杂性
对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
视图与控制器间的过于紧密的连接
视图与控制器是相互分离，但却是联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
视图对模型数据的低效率访问
依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
一般高级的界面工具或构造器不支持模式
改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，会造成MVC使用的困难。
原文地址：https://www.cnblogs.com/yuezhihao/p/9097144.html