Web世界中，Struts2身处何方

 今天，摆在开发人员面前的是众多的Web开发框架。它们有些来自于开源社区，有些来自于商业公司，还有些是由某些团队内部开发的，以满足当前Web开发所需。目前大约一共有 超过 40 个开源框架，这个数目看上去挺大，但也许还有同样多（如果不是大大多于这个数量的话）的内部构建的框架部署在产品环境中。既然我们有这么多选择，那为什么要选择 Struts2 呢？下面列出的这些特性，可能会促使你把 Struts2作为你的选择：

ƒ  基于 Action的框架
ƒ  拥有由积极活跃的开发人员与用户组成的成熟社区
ƒ  Annotation和 XML配置选项
ƒ  基于 POJO并易于测试的 Action
ƒ  与 Spring，SiteMesh 和 Tiles的集成
ƒ  与 OGNL表达式语言的集成
ƒ  基于主题的标签库与 Ajax标签
ƒ  多种视图选项 (JSP，Freemarker，Velocity和 XSLT)
ƒ  使用插件来扩展或修改框架特性。

在选择一个框架的时候，框架风格的选择是最具有争议性的。让我们先来了解一下 Web 应用的发展过程，然后再来看看我们是怎样走到今天的，以及在现在的 Web 开发场景中Struts2 到底占据了什么位置。

Servlets

Servlets 是 Java 在 Web 应用中的开创性的尝试。在遵循 HTTP协议的前提下，Servlets 可以将 URL 映射到一个特定的类上，而该类中的方法将会被调用。 人们马上就意识到，虽然这是一次大踏步式的前进，但是这种在 Java 代码中生成 HTML 代码的方式，对项目维护而言简直就是一场噩梦。每次当用户界面发生了变化，Java 开发人员就需要更改Servlet代码，重新编译，然后把应用重新部署到服务器上。

SP和Scriptlet开发

这种“维护噩梦”的后果，又导致开发风格的正好颠倒。现在人们不是把 HTML 代码放在 Servlet 或者 Java 代码中，而是把 Java代码（作为 script-lets）放在 HTML 代码中——这就是 Java Server Pages (JSP)。每一个 JSP都同时负责处理请求和页面表现。

一个问题得到了解决，而另一个问题却又出现了。在 JSP 中，Java 代码的使用方式和在类中一样，但这里却没有方法和类的结构。在早期的每一个 JSP文件中，都可以找到以下两种情况之一：  剪切和粘贴的代码 —— Java 代码从一个 JSP 中复制到第二个，第三个，等等。这种情况会导致在原始代码中存在的缺陷或者错误传播开来，并且大大增加了工作量，因此必须要对此做出改变。  调用通用的 Java 格式化对象——通用的格式化代码或者是逻辑代码被组织到一个可重用的对象中，然后每一个 JSP都会使用这个通用的对象。基于这些情况，一种最佳实践，或者可以称之为一种模式，就应时而生了——在 JSP中使用 Java对象。 随着 JSP 规范的进一步完善，标签开始被引入进来对可重用的Java 对象进行封装。标签提供了用以访问底层代码的表层代码，它与 HTML 很相像，设计人员（而不是开发人员）和 IDE 可以通过它与动态内容交互，组装出页面布局。像<jsp:useBean.. />和<jsp:getProperty.. />就是 JSP 所提供的标签。JSP 在提供了一系列标签库的同时，还可以支持开发人员创建自定义的标签库。


基于Action的框架

基于 Action的框架把 Servlet和 JSP的概念合并到了一起。它的想法是把对当前用户所见的页面请求的处理动作，分拆成处理逻辑和表现逻辑，让它们各司其职。这种实现方式使用了源自于Smalltalk 的一个模式，名为模型-视图-控制器——最近的叫法是前端控制器，而 Sun则给它起名为 Model 2。  在这个模式中，Servlet 是控制器，集中处理所有的客户端页面
请求。它把所请求的 URL与被称为 Action的工作单元映射到一起。Action 的工作就是通过访问 HTTP 会话、HTTP 请求和表单参数等调用业务逻辑，最后把响应映射到以 POJO（plain old java object）形式存在的模型上，来完成特定的功能。最后，Action 返回的结果会通过配置文件映射到 JSP页面上，JSP会渲染视图并显示给用户。

Struts2是一个基于 Action的 MVC Web框架。


基于组件的框架

当 Web 应用变得更加复杂的时候，人们便意识到一个页面已经不再是一个独立的逻辑了——一个页面上会存在多个表单，有内容更新的链接，还有其他很多自定义的 Widget——而这些都需要进行逻辑处理来完成各自的任务。出于解决这种复杂度的需要，基于组件的框架开始流行起来。它们在用户界面组件和表示这些组件的类之间提供了一层紧密的连接，它们是事件驱动型的，并且比起基于 Action 的框架而言，更具有面向对象的特征。一个组件可以是一个 HTML输入框，一个 HTML表单，框架所提供的或是开发人员创建的 Widget。像提交表单或者是点击链接这样的事件，都与代表组件的类的方法或者是特定的监听类，有着一对一的映射关系。基于组件的框架还有一个好处，那就是你可以在多个 Web 应用之间重用组件。JSF，Wicket 和 Tapestry等都是基于组件的框架。

伟大的均衡器——Ajax

在 2005年初，Web应用又增异彩。按照 Jesse James Garrett的说法， Ajax的全称是 “Asynchronous JavaScript and XML”。 相对说来，这些技术没有一样是新的。实际上，早在 6年以前（从 Internet Explorer 5开始），可进行异步调用的主要 Web浏览器组件——XMLHttpRequest对象就已经提供了支持。 

真正推陈出新的是这些技术的应用。Google地图第一个完全利用了这项技术所带来的好处在 Google地图中，网页是活动的，你可以通过各种窗体组件与它进行交互。你可以用鼠标来拖动屏幕上的地图；当你输入一个地址时，相关信息还会在地图的对应位置显示出来；最后，当它们都与 Web程序完美结合以后，Web应用终于攀上了新的巅峰。这些操作都不会带来页面的刷新！

当用户界面与 Ajax结合以后，Web浏览器就可以只在必需的时候，才会向服务器发起请求，获得少量的信息。服务器返回的结果都是被格式化或者处理过的，页面会直接把结果显示出来，然后用户就可以在浏览器中看到变化。因为只有发生变化的那一块区域会被重新渲染，而不是整个页面进行刷新，所以对于用户来说，响应速度就变得更快了。

从 UI发出的请求和事件很相似——它们是不连续的，所传递的只是一个单独的组件或者功能的信息。现在的操作已经再也不需要获取整个页面的信息了，它们变得更加精细，跨应用的可重用性也变得更高。其结果就是，当一个 Ajax用户界面调用基于 Action的框架时，这个 Action框架的反应机制就和基于组件的框架非常相似。实际上，这二者的结合为我们带来了耦合度更低、可重用性更高的系统。同样的操作，可以为 Ajax组件提供 JSON、XML或者 HTML片段视图，又可以和其他操作组合，为非 Ajax的用户界面提供HTML视图。
 
核心组件

从全局的角度来看 ，Struts2是一个 pull（拉）类型的 MVC（或者 MVC2）框架，它与传统类型的 MVC 框架的不同之处就在于在Struts2 中，Action 担任的是模型的角色，而非控制器的角色，虽然它的角色仍然有些重叠。“pull”的动作由视图发起，它直接从Action 里拉取所需的数据，而不是另外还需要一个单独的模型对象存在。

我们刚刚从概念上讲述了一下 Struts2里面的 MVC，那么从实现的层面上来看又是什么子呢？在 Struts2 中，模型-视图-控制器模式通过五个核心组件来实现——Action、拦截器？值栈/OGNL？结果类型和结果/视图技术。

在阅读时要注意一点，这里的讲解只是帮助读者掌握一些背景知识，并没有采用最有效率的配置方式。