MVC
MVC是ModelViewController的简称原本是建立Smalltalk 应用的框架框架支持代表应用状态屏幕表现和控制流的个类他们分别叫做ModelView和Controller
在Model发生变化的时候通知View改变在View需要查询状态的时候向Model发送请求当View做出一个动作时比如对数据的修改等通知ControllerController得到状态改变信息时发送请求给Model并且Controller负责选择显示新的View
下图是典型的ModelViewController范式经常被表示为一个互相连接的三角形
图 MVC 通常表示为个互相连接的组件在Design Patterns: Elements of Reusable ObjectOriented Software一书中作者以smalltalk MVC为例赞扬了通知/订阅者（notify/subscribe）协议和观察者（Observer）模式的使用其中局的一个经典的例子是对同一数据系统可能需要不同的显示视图比如条形图饼图数据表格等等如下图
图不同的View使用相同的Model图所示的每种视图可能在同一时间显示给不同的用户应用必须保证在其下面的数据或者模型改变时视图的更新为改变模型用户提交一个请求给控制器由控制起来配合改变模型数据视图必须跟着改变以反映最近的模型改变状态
Smalltalk MVC 方案使用观察者通知模式在这种模式下每个视图注册为一个模型数据的观察者然后模型可以通过发送消息给所有这册观察者通知它们相关的改变其为 Smalltalk MVC 框架已经通用化了他也可以应用它其他平台上面
Model
Model是Sun公司为了解决JSP不易维护和功能块难以复用提出的Sun的技术人员提出使用JSP 和 SERVLET同时来部署web 应用SERVLET可以应付控制流而 JSP则可专注于讨厌的编写HTML的任务
结合使用 JSP 和 SERVLET 开始被称为Model 而单独使用JSP称为Model
Model并不是什么新的东西其思想上实际是对MVC的一种继承很多场合交互使用Model 和 MVC这两个词但是还是存在一些争论即一个应用是否是 MVC以及是否支持经典的观察者通知模式没有观察者通知的ModelViewController 有时被称为MVC 或Web MVC
层模式的MVC结构
人们认为Model不同于MVC的主要原因之一是基于观察者/通知模式的经典的MVC是难以在web环境下实现的
因为HTTP协议是一个请求/响应协议客户端有请求服务器端才会有响应没有请求就没有响应而观察者/通知模式要求在服务器端发生变化时能主动给用户端发消息更新
为了解决经典MVC模式难于在web环境下实现的问题引入层模式将状态改变和状态查询的职责加于控制器之上并伴随着改变通知
如图分层的web 应用使用一种比传统MVC模式更加扁平的模式控制器被夹在表现层(View) 和 应用逻辑 (Model)之间
图web应用的层模式每个组件的主要职责并没有改变流程有轻微改变View不再与Model有直接的联系而它们之间的交互都通过Controller即查询状态和改变通知都必须通过控制器当视图或者表现层需要加工动态页面时它使用从控制器传递的数据而不是直接来自于模型层这种改变去除了View 和 Model的耦合允许控制器选择数据和显示这些数据的视图
Struts概要介绍
Struts实现层模式的MVC
Struts是一个应用框架它实现了层次化的MVC模式或者说Sun公司提出的Model模式
在Model模式的web编程中Model部分可以交给EJB及JDBC实现而View部分可以由Jsp完成但是却没有合适的工具完成独立的Contrroller在Model的思想提出由Servlet应付控制流在Struts中Servlet就扮演了Front End Controller的角色
当客户端提出请求ActionServlet响应请求并且在指定的StrutsConfigxml文件中查到请求对应的Action（Action是Struts引入的一个核心类作为Back End Controller在后文会介绍）对已经实例化的ActionActionServlet为这个新的请求开一个线程对未实例化的ActionActionServlet将其实例化
Action作为Back End Controller可以与Model部分交互以实现状态改变或者状态查询Action还将返回下一步的视图选择给ActionServletActionServlet根据对应的StrutsConfigxml找到视图选择对应物理地址并把新的View返回给用户端
图 Struts实现层模式的MVC结构另一种常见的关于Srtuts实现MVC模式的看法是认为只有ActionServlet是Controller而把Action看作BusinessLogic我认为这种看法是没有前一种将Action视为Back End Controller的看法合理的因为Controller部分需要完成的视图选择实际上是由Action实现的
之所以会有后一种不太合适的关于Struts实现MVC结构的看法存在主要是起源于编程习惯问题很多人喜欢把大量的业务逻辑交给Action处理我认为这是不太合适的一方面这样降低了代码的可复用性另一方面使Action看起来臃肿降低了可读性所以推荐的编程方式是把大量的业务逻辑抽出做成JavaBean以解放Action
