第1章WebWork的概貌
本章涵盖：
■  为什么MVC是重要的
■  框架和容器
■  WebWork的背景和未来
■  CaveatEmptor范例程序
4 WebWork in Action
中文版
我们首先设想一个情景：你刚刚完成一个1.0版的Web应用程序并发布了，而你的大客户却立即提出了要求——在1.1的版本中，用户界面必须进行很大程度的修改以符合他们公司的使用标准。修改几乎涉及了
所有方面：从数据录入表单上的字段数量到按钮及图像的位置，再到各种向导所包含的步骤数量，等等。而且客户要求在下个星期前完成这样的修改！
面对这样的挑战，你可能会气定神闲，不动声，也可能想着要准备简历换东家了。
这天渊之别取决于你的Web应用程序是如何构建的。在早期的Web应用程序开发当中，程序员通常会使用像Perl这样的脚本语言，通过脚本将需要显示的内容直接打印出来。
同时，这些脚本中也包含了关键的商业逻辑。很明显，这种方式将核心的商业代码和表现层紧密耦合在一起了。
时至今日，像Perl、PHP、JSP、ASP这些类库和其他支持Web开发的语言都在设法解决商业逻辑代码和表现层代码之间的解耦合问题。若想满足用户的需求就像在公园里散步一样轻松，就取决于使用的类库，以及你是否能够充分发挥它的优越性了。
在本书中，你将会学到如何使用Java领域中最流行的Web框架之一：WebWork。
WebWork是一个优越的框架，它的设计基于这样一个基本原理：完成通用任务应该是简单的，而构建高级的设计也应该是可行的。WebWork的开发者只想提供一个能够为你工作的框架，而不是一个与你作对的框架。
为了帮助你学习WebWork，我们将向你演示如何使用WebWork基本及高级的特性构建一个改进版本的应用程序CaveatEmptor。CaveatEmptor最初出现在《Hibernate in Action》（Manning Publications，2004年，www.manning/bauer）一书中。Hibernate 是一个简化了数据访问方式的对象关系映射（ORM）框架。该书的作者——Christian Bauer和Gavin King通过CaveatEmptor这个在线拍卖程序展示了Hibernate的特性。虽然CaveatEmptor是一个完整的应用程序，但是它并没有任何基于Web的用户界面。
在本书中，我们将演示如何使用WebWork的特性为原来的CaveatEmptor代码增加一个Web前端。我们选择这种方式介绍WebWork及它的特性是有以下几个理由的。首先，许多WebWork的用户也使用Hibernate，所以在CaveatEmptor上进行扩展可以让大家看到集成两者的最佳方式，而许多《Hibernate in Action》的读者也可以学习如何利用WebWork给CaveatEmptor增加一个Web前端。那些精通编写后端代码却不精于前端代码编写的朋友可以通过本书来了解前端的实现。
在探究WebWork的特性和CaveatEmptor之前，我们首先了解隐含于Web应用程序框架中的通用概念。在第2章“WebWork方式的HelloWorld”中，我们将通过熟悉的“Hello, World”指南向你展示使用WebWork的基本要领。再次提醒各位读者，我们将完全专注于WebWork的特性及如何在CaveatEmptor应用程序中使用这些特性。
在此之前，你需要明白WebWork是什么，以及它设法实现什么。言简意赅地说，WebWork解决了显示逻辑和业务域逻辑的解耦合问题。但是这句话意味着什么呢？为什么这个问题如此重要？解耦合的概念是从何而来的呢？更深入一些，WebWork所基于的MVC模式又是什么呢？
第1章
5
WebWork的概貌
1.1  为什么MVC是重要的
从表现层中分离域对象并不是Web应用程序所特有的问题，这在GUI应用程序中同样存在。Model-View-Controller（MVC）模式最初就是由SmallTalk社区开发出来，用
以解决GUI应用程序存在的这个问题的。MVC寻求一种模式将应用程序分为3个部分
并且详细定义这3个部分之间的交互，从而降低它们之间的耦合度，让每一部分都专注
于自己职责，无须担心其他部分。
虽然原始的MVC模式在桌面GUI应用程序中发挥了很好的作用，但是它并不能直接应用到网络世界中，因为请求/响应模式组成了超文本传输协议（HTTP），限制着Web
的行为。随着开发者不断改进自己的Web开发技术，MVC的发展冲破了这个限制，而
MVC的核心概念并没有因发展而有所改变。WebWork则继续延续这种发展的动力，这
足以和多年前SmallTalk开发人员的经历相媲美。
MVC设法减少可复用的域模型（Domain Model）与显示相关代码之间的联系。它通过在显示层与域对象之间引入一个控制器来实现这一点。控制器处理来自显示层的事
件，例如点击按钮，并将事件映射为域模型的改动。控制器也通过注册显示层以获得域
模型改变的通知，从而令显示层能够更新。举例来说，应用了一个不同的显示层，并不
需要改变基础的域模型和控制器层（Controller Layers）。
MVC框架已经成为在Web应用程序开发中具有统治地位的架构了。WebWork是一个MVC框架，还有另外一些基于Java的MVC Web应用程序框架，像Struts（已经不再处于
快速的开发状态了1）、Tapestry、RIFE和JavaServer Faces（JSF）都十分流行。在我们关
注基于Web的MVC设计之前，让我们来简单回顾一下最初用于桌面GUI应用程序的MVC
设计。了解最初MVC的流程将会帮助你理解MVC所经历的改进，因为这些改进已经应用
到WebWork中，或者特别地说，在WebWork中已经实现了这些改进。
1.1.1  经典MVC落伍了
图1-1展示了在经典MVC中的事件流。用户与视图（View）进行交互，填入数据并点击按钮，控制器（Controller）接收到来自视图的事件并对模型（Model）进行操作，
根据用户提供的数据更新模型（Model）。视图也会接到“模型改变”的事件通知，因此
它会随着模型而更新，将模型更新的结果显示给用户。我们通过注册更多的事件
对多个视图和控制器进行配置，以便让它们使用相同的共享模型。这种模式在单机且实
时更新的应用程序中可以起到很好的作用。但是，在Web世界中，这种经典的MVC模
式就失效了。在Web世界中，视图是在客户端的浏览器中生成的，而控制器和模型则是
在服务器端，图1-1很清楚地展示了设计的方法。但糟糕的是，这在HTTP和HTML的
世界里是行不通的。因此，使用HTTP请求/响应模式的Web应用程序需要一个与MVC
截然不同的设计，这个设计借用了MVC的名称和一些方式。
1译者注：在本书的翻译过程中，WebWork与Struts进行了合并，新框架的名称为Struts Ti。
6 WebWork in Action 中文版
图1-1  经典MVC 模式的事件流
jsp用什么前端框架1.1.2  经典MVC 模式的更新：前端控制器（Front Controller ）
在Web 版本的MVC 中，视图是不能如图1-1所示的那样直接调用控制器的，但是可以基于Web 请求映射成不同的URL 。视图不是一个可以被更新的对象，而是在客户端发出一个新请求的时候随之重新呈现的Web 页面。同时，模型也不能将自身的改变通知视图，因为视图呈现于另外一台计算机的用户浏览器中。因此，视图每次都需要依照最新的数据重新生成。
图1-2展示了应用在Web 应用程序的
MVC 事件流。在Web 世界中的经典MVC
应用程序是通过使用前端控制器（Front
Controller ）模式来实现的。这个模式包含了
一个分发器（在Java 的Web MVC 实现中，
通过Servlet 来实现分发器），而分发器将请
求URL 映射至需要被执行的命令实例
（Command Instance ），命令实例在WebWork
或者Struts 中就是action 。action 与系统后端
的服务进行交互，通常这些服务会组合在一
起作为模型。命令实例在处理完业务逻辑之
后返回一个码值，而这个返回码会映射到某
一个视图（通常是一个Web 页面模板，譬如
JSP ）。最后，结合控制器和模型，视图将会呈现给用户。通常视图会使用标签库，以便
更简单地访问数值。
图1-2  Web 应用程序中的MVC 事件流
第1章
7
WebWork的概貌
1.1.3  MVC演化：页面控制器（Page Controller）
一种稍微有些不同的MVC实现已经通过一些框架，譬如Microsoft的ASP.NET2，流行起来了。在这种MVC中，并不是令分发器去寻一个控制器并执行之，而是直接到达
视图并且在继续生成视图之前调用相应的控制器。尽管这种模式丢掉了在大多数经典
MVC实现中所使用的某些解耦合特性，但是它可以提高开发效率并且拥有工具的支持
（Microsoft的Visual Studio尤为明显）。WebWork通过使用<webwork:action>这个自定义
标签也支持这种开发方式。
前端控制器与页面控制器的对比
图1-3和图1-4展示了控制面板的两种实现——前端控制器实现和页面控制器实现之间的区别。由于X、Y和Z部分职责的分离，页面控制器可能看起来更加模块化一些，
但是良好的面向对象设计也可以实现一个模块化的前端控制器。如果你熟悉Struts，前
端控制器模式看起来会更熟悉。即使你不熟悉其他的Web框架，前端控制器模式也应该
是收集并呈现数据的最直接的方式了。尽管如此，一些框架则因为页面控制器模式鼓励
封装而应用之，如图1-4所示。幸运的是，WebWork同时支持这两种实现，将两者的优
点都呈现于你的面前。
根据我们的经验，框架可以极大地提高开发效率。为了能够满足用户的需求并且应对来自不断改变的商业世界的挑战，我们强烈推荐你在构建Web应用程序的时候充分发
挥MVC设计模式的优势。事实上，绝大多数的开发人员并不会自己从零开始写一个MVC
框架，而是在已有框架（譬如WebWork）的基础上进行改进。
图1-3  使用前端控制器MVC模式设计的控制面板的实现
2  Microsoft有一个有趣的关于表现层设计模式的讨论，你可以从www.microsoft/china/MSDN/
library/architecture/patterns/esp/EspWebPresentationPatterns.mspx到它。讨论包括页面控制器和前端控制器
模式。页面控制器已经内建于框架之中，而前端控制器的实现则需要自己从零开始构建了。
8 WebWork in Action
中文版
图1-4  使用页面控制器MVC模式设计的控制面板的实现
1.2  理解框架和容器
从根本来说，WebWork是一个MVC框架，但同时它也是一个轻量级容器。为了帮助你更好地了解框架与容器之间的差别，我们将看一下两者各自所提供的功能，同时我们也将关注两者相关及特有的几种技术。
1.2.1  什么是框架
在Rickard Öberg（WebWork的创造者和JBoss创始人之一）构建最原始版本WebWork的时候，他曾经说过：“框架的强大之处不是源自它能让你做什么，而是它不能让你做什么。”Rickard所说的话解释了什么是框架：框架使混乱的东西变得结构化。
而Web应用程序框架则鼓励开发人员使用一系列框架所提供的基础类和类库，从而避免杂乱的JSP所造成的混乱。
我们再来打个比方。框架就像是一间有很多屋梁的房子，当你需要扩建房子的时候，譬如增加新的房间、窗户和过道或者在卧室增加一个壁炉，由于屋梁的限制，你并没有什么其他的选择。虽然较少的屋梁和架构会让你有更多的选择，但是当台风来袭或者发生地震的时候，你让家人住在这样一间只有屋顶的房子里，恐怕不会觉得安全吧。总之，框架是在结构和创造力之间的一个精确的天平。
由于框架要求更多的结构，你的创造力所拥有的发挥空间开始收缩了。一种极端是框架消失了，一片
混乱；而另一种极端就是框架留给你的选择是如此之少，以至于你无法完成你的应用程序。很明显，一种完美的中间状态存在于这两个极端之间的某一处，而这种中间状态就是WebWork和所有其他MVC框架所梦寐以求的。
1．WebWork鼓励创造
Struts是一种流行的Java Web框架，它和WebWork有很多相似之处。但是，在构建大规模Web应用程序的时候，它并不能提供通常所需的创造力发挥的空间。例如，两

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。