MVC设计模型
MVC 是一种著名的设计模式，特别是在 Web 应用程序领域。模式全都是关于将包含业务数据的模块与显示模块的视图解耦的。这是怎样发生的？视图（例如，JSP 页面）怎样能够与其模型（例如，包含数据的 JavaBean）解耦？记得这句格言么？一个层次的重定向几乎可以解决计算机业中的所有问题。确实，在模型和视图之间引入重定向层可以解决问题。此重定向层是控制器。控制器将接收请求，执行更新模型的操作，然后通知视图关于模型更改的消息。依赖于模型的状态并且依赖于请求的控制器可以决定要显示哪个视图。
没有mvc模式之前，我们的web数据请求流程大概是这样的
从图上看出视图层和模型层之间是连通的，所以耦合性是存在的
那么，mvc出现时，我们的请求流程就应该是这样的。
从图上看，视图层和模型层之间没有直接联系，而是通过控制层交换数据
springmvc做了哪些解耦合
解耦一：
springmvc一方面全面实现了mvc的设计理念，在这里我将它的运行原理图贴出来
可以看出，这种流程结构完美诠释了一句设计格言“一切的重定向都可以解耦合”
解耦二：
springmvc利用spring强大的IOC技术（反转控制 inversion of control），它使应用程序高度解耦，提供了通过简单的配置更改即可动态更改组件的灵活性。
springmvc的核心架构具体流程在这提一提：
1.客户端发来请求—-》经过web.xml文件中的dispatcherservlet进行判断，拿到请求映射路径
2.dispatcherservlet将映射路径交给HandlerMapping解析，HandlerMapping会找到匹配的controller（我们自己写的类），并将这个controller对象封装起来，交给HandlerAdapter处理
3.HandlerAdapter拿到这个包装后的controller，调用其中的方法，将返回的数据和视图名封装在ModleAndView（mv）对象中，返回给我们的dispatcherservlet，
4.dispatcherservlet紧接着拿着mv交给视图层，视图层拿到页面，并使用el技术将数据渲染在页面，呈现给我们的客户端。
所以，整个过程下来，我们的模型层（实体模型+service层+dao层）并没有接触视图层，之前我的一片博客中提过原始的web请求的处理流程
http://blog.csdn.net/headingalong/article/details/54836585
会跟现在的mvc设计模式有很大的区别。
struts2的设计模式
作为web层的框架，struts2也是经典的一款，因为它优秀的设计理念，完成了模型层和视图层的解耦，有方便我们的开发人员更为高效的模块开发。
struts2流程跟springmvc有很大的相似，都使用了前端控制器，它的实现是strustsPreparedAndExcecutorFilter,
先看看它的执行流程图
在这里我也说说struts2基本的流程吧
1.客户端发送请求过来，经过我们的前端控制器，
2.前端控制器拿到映射路径，去找ActionMapping要action对象，ActionMapping的作用是将所有的action和映射路径一一对应并进行管理，向前端控制器返回一个action，
3.前端控制器拿到action之后创建一个代理对象actionproxy，这个代理对象经过核心的20个拦截器（环绕增强，完成部分拟定的功能）再执行，返回一个逻辑视图。
4.strustsPreparedAndExcecutorFilter调用ExecuteOperations执行请求返回页面视图。
两种框架的性能差别
现在springmvc能深入人心，得益于它可以将参数封装的设计。
1.springmvc是基于方法的开发（一个url对应一个方法）请求参数作为方法的形参在方法中处理，这样可以设计为单例或者多例（推荐单例）。struts2是基于类的开发，请求参数作为类的属性，这样必须设计为多例，才可以同时处理多个请求，这样的缺点就是很费服务器资源，给服务器很大的压力，降低服务器的处理速度。
2.struts2利用值栈存取请求或者响应的数据，使用ognl表达式来存取数据，springmvc使用参数解析器将请求参数解析并赋值到方法中的形参，最后又将modelAndView中的数据放到request域中，页面使用el表达式解析数据。