MVC架构模式实例
一、简介
什么是MVC呢？MVC架构模式，也就是Model View Controller模式。它是一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
说起来好像是很复杂，但是我对它的理解也就是各自处理自己的任务。
模型:负责封装并实现应用的具体功能。可以实现系统中的业务逻辑，通常可以用JavaBean来实现。
视图:用于与用户的交互。用来将模型的内容展现给用户。用户可以通过视图来请求模型进行更新。视图从模型获得要展示的数据，然后用自己的方式展示给用户，相当于提供页面来与用户进行人机交互。比如用户在登陆注册界面完成信息的填报后点击确定，由此来向控制器发出这个请求。
控制器:是Model与View之间沟通的桥梁。用来控制应用程序的流程和处理视图所发出的请求。当控制器接收到用户的请求后，会将用户的数据和模型相映射，也就是调用模型来实现用户请求的功能。然后控制器会选择用于响应的视图，把模型更新后的数据展示给用户。
MVC模式的这三个部分的职责非常明确，而且相互分离，因此每个部分都可以独立地改变而不影响其他部分，从而大大提高应用的灵活性和重用性。
二、目的
使用MVC的目的是将Model和View实现代码分离，也就是前台html表现层和后台php逻辑层分离。这样做便于开发，代码优化，界面交互性好。
归根结底，其目的就是便宜项目开发。
三、特点
MVC重要特点就是两种分离：1.视图和数据模型的分离：使用不同的视图对相同的数据进行展示；分离可视和不可视的组件，能够对模型进行独立测试。因为分离了可视组件减少了外部依赖利于测试。（数据库也是一种外部组件）2.视图和表现逻辑(Controller)的分离：Controller是一个表现逻辑的组件，并非一个业务逻辑组件。MVC可以作为表现模式也可以作为建构模式，意味这Controller也可以是业务逻辑。分离逻辑和具体展示，能够对逻辑进行独立测试。
四、适用环境
做产品，做大项目的时候，最好使用，因为那时参与的人多，进行模块调用方便，而且便于管理。
五、解决的问题
它解决的问题有：维护难，开发速度慢，二次开发难度高，工作量大，代码复用，耦合度高，系统不灵活。
六、解决方案
MVC 的基本原理就是通过Controller 连接View 和Model。也就是说，当View 中显示的数据变化时（如ListView要删除某个列表项），会通知Controller，而不是直接通知Model。这时Controller接到View的通知后，会在Model 中采取相应的动作（如删除数据库中的某条记录）。如果模型的数据发生变化（如插入、删除数据库中的记录），会将变化通知控制器，然后控制器会通知视图重新显示数据。
七、实例
应用于基于MVC架构模式的框架，常见的服务器端MVC框架有：Struts、Spring MVC、ASP.NET MVC、Zend Framework、JSF。
以SpringMVC为例来解释下MVC在spring的工作流程中如何体现的。
SpringMVC是一个MVC的开源框架，springMVC=struts2+spring，springMVC就相当于是Struts2加上sring的整合，可以简单的把springMVC理解为是spring的一个模块（类似AOP，IOC这样的模块），网络上经常会说springMVC和spring无缝集成，其实springMVC就是spring的一个子模块，所以根本不需要同spring进行整合。
SpringMVC的工作原理图：
1).在请求离开浏览器时，会带有用户所请求的内容的信息，比如请求的URL和提交的表单信息。
2).SpringMVC的所有请求都会通过一个单实例的前端控制器DispatcherServlet，该Servlet将请求委托给应用程序的其他组件来执行实际的处理。
3).DispatcherServlet的任务是将请求发送给Spring MVC控制器。控制器是一个用于处理请求的Spring组件。在典型的应用程序中可能会有多个控制器，DispatcherServlet会根据请求所携带的URL信息来确定将请求发送给哪个控制器。一旦选择合适的控制器，DispatcherServlet会将请求发送给选中的控制器并耐心等待控制器处理完毕。
4).控制器在完成逻辑处理后，会返回给用户在浏览器上显示的模型数据，并且标识出用于渲染输出的视图名。最后将请求连同模型model和视图名发送回DispatcherServlet。
5).DispatcherServlet会使用视图解析器来将视图名匹配为一个特定的视图实现，它可能是也可能不是JSP。
6).DispatcherServlet将数据模型交付给特定的视图，请求的任务就完成了。
7).视图将使用模型数据渲染输出，这个输出会通过响应对象传递给客户端。
例如①，小时候玩的那种卡带式游戏机，Control是主机，一般来说我买一个主机就行了，只要他不坏，他就能一直让我玩这一类的游戏。View则是电视机和游戏手柄，电视机可以独立工作，他不管输入的是电视信号、影碟机信号还是游戏机信号，他只管显示，而且他决定了我们看到的效果是怎么样的，如果我想要个尺寸更大的或者彩色的显示效果，我只需要买个相应的电视机就行了，手柄也是可以换的，遥杆还是带震动的。Model则是游戏卡带，他决定了我玩的是什么游戏，是魂斗罗还是超级玛莉，而且游戏机主机和电视机生产厂家永远也不知道在上面有可能会运行什么样的游戏。卡带中可能会有游戏代码和存储单元，都根据游戏的需要而设计。
例如②，一个采用比例表示的用于政治选举的一个简单信息系统，它提供了一个输入数据的电子数据表和表示当前结果的几种图标。用户可以通过图形接口与系统交互。所有信息显示必须立即反应出选举数据的变化。（引用自《面向模式的软件体系结构-卷1 模式系统》）
八、优缺点
优点：
1.耦合性低
视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。
2.重用性高
随着技术的不断进步，需要用越来越多的方式来访问应用程序。MVC模式允许使用各种不同样式的视图来访问同一个服务器端的代码，因为多个视图能共享一个模型，它包括任何WEB（HTTP）浏览器或者无线浏览器（wap），比如，用户可以通过电脑也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面使用。MVC使开发和维护用户接口的技术含量降低。
3.部署快
使用MVC模式使开发时间得到相当大的缩减，它使程序员（Java开发人员）集中精力于业务逻辑，界面程序员（HTML和JSP开发人员）集中精力于表现形式上。
4.可维护性高
分离视图层和业务逻辑层也使得WEB应用更易于维护和修改。
5.有利于软件工程化管理
由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。控制器也提供了一个好处，就是可以使用控制器来联接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。给定一些可重用的模型和视图，控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。
缺点：
1.增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
2.视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。
3.视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。
4.目前，一般高级的界面工具或构造器不支持MVC模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成使用MVC的困难。
5.没有明确的定义。完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。
