【 tulaoshi.com - 编程语言 】
Struts是雅加达的一个项目，它提供了一个方法，可以在一个Web应用程序中一起使用JavaServer
Pages（jsp）和servlets。它的目的是要解决完全由JSP或完全由servlet实现的应用程序中的固有的问
题。 例如，servelts可以生成Html页面，但这么做很麻烦。另一方面，JSP可以很轻易地用于传统的
HTML页面，但JSP页面有其它的缺点。非凡是，用JSP很难将内容同内容的显示分开。 很轻易将Java 代
码同HTML混在一起，结果做出的东西又慢又难以维护。
然而，因为JSP页面轻易使用，所以它们成为用Java构建动态的Web应用程序的首选方法。除了轻易编程
外，JSP页面也被改进了，所以现在它们克服了以前的某些局限性。JavaBeans和标记库只是在基础的
JSP技术上的几个改进。这种类型的方法——JSP页面单独负责处理输入的请求和回复客户端——被称为
Model 1架构。
JavaServer Pages是servlets的非凡情况，所以两者可以一起工作以弥补每个的不足，这似乎是合乎逻
辑的。这种类型的方法——你的Web架构包含截然不同的但又互联的处理数据模式、显示代码和程序控
制逻辑的JSP和servlet组件——被称为Model 2架构，或Model-View-Controller（MVC）架构。
为了使用Struts架构以及用JSP和servlets有效地编程，对MVC架构的了解是很必要的。Model 1和MVC架
构的主要不同就是请求是在哪里处理的。在Model 1架构中，请求通过JSP接收，主要通过JSP处理。如
果JSP页面需要来自任何其它应用程序组件的服务，如一个数据库，那么你就从页面做适当的调用，把
数据返回到页面，安排数据的格式并显示出来。你可以把一些代码放到一个或多个JavaBean中，但是这
么做本身没有将逻辑同显示完全分离。
MVC方法采用了JSP和servlet方法的最佳特性，使这两种技术可以协同工作。明确的是，servlet是处理
层（控制器）。Servlet接收请求，很像Model 1架构中JSP页面所做的那样，并确定如何满足那些请
求。这就意味着，servlet控制输入的请求和输出的回应。
商业逻辑体现了MVC架构中的模式。商业逻辑代码为页面做处理。假如进入servlet的请求是一个数据库
查询，servlet就将这个请求传送到一个SQL调用或类似的数据库代码。假如请求是一个包括输入信用卡
号的购买请求，那么事物处理代码就接管了。在某种意义上，架构的模式部分是让应用程序处于领先地
位的全部原因。
JSP页面是显示层（视图），是用户与应用程序交互的地方。它提供输入并显示结果。页面不应该包括
任何脚本。它只是将数据传送到servlet，并接收和显示返回的数据。
该架构的优势应该是很明显的。首先，它将计算和显示清楚地分开了。结果很理想，在JSP页面上没有
出现处理过程，在servlet或商业逻辑中没有数据格式。这种分离的另一个好处是Java程序员可以专注
于servlet代码，HTML编写者可以专注于JSP。 第二点，控制器servlet做页面上的所有的决定。 在你
的页面和逻辑中不会出现任何决策。这就提高了一个应用程序的性能和可扩展性，因为请求可以被导向
架构的不同的组件，甚至是不同的服务器。
运用MVC架构
MVC架构没有必要成为用于所有Java应用程序的最佳方法。 如你想象的那样，它在预备和编码时往往很
复杂——这对简单的应用程序来说是没必要的。当页面导航相对来说比较简单和固定，而且应用程序中
的页面结构可以由一个简单的目录结构治理时, Model 1架构仍然是最好的方法。这些应用程序往往将
页面流动信息嵌入到页面间的链接中。（JSP中出现forward()就告诉你，在该页中有嵌入的逻辑，让你
对显示下一页作出决定。）对于对流量或可扩展性需求有限的静态的应用程序来说，标准的JSP模式仍
然是一个可行的选择方案。
在一些情况下，你可能想把一个JSP应用程序移植到MVC架构中。例如，你可能开始时用的是Model 1，
简单的JSP架构，随着你的需求的增加，你会发现维护起来太复杂或太难了。假如你花很长的时间对应
用程序做相对来说较简单的修改，或者假如你经常在你的代码中发现bug，那么你的JSP导向的应用程序
也许就不再是合适的方法了。
随着应用程序的发展和变化，页面的流动和商业逻辑也增加了。应用程序变得难以维护，因为页面流动
逻辑跨多个页面分布，而且商业逻辑可能开始存在于未计划的地方。从Model 1转到MVC的最佳时机就是
当这些类型的维护问题出现的时候。
你也可以预先计划将你的应用程序从一个架构移植到另一个架构。当你的应用程序中的JSP页面包含脚
本元素，定制标记或javascript来执行一个forward()操作时，你可能想调整你最初的设计，变成一种
用MVC架构的设计。
Refactoring用在这儿是个不错的术语。它指的是以一种高度严谨的方式重建代码结构的一种技术。当
你的代码变得难以理解、修改和调试时，你通常就开始考虑调整了。你可以用几种方式来调整代码：你
可以简单地重新命名变量和方法，或者将部分代码移植到不同类型的执行模式中。更多的关于调整及其
技术方面的信息，请访问Martin Fowler的网站www.refactoring.com 或者阅读他写的书
Refactoring: Improving the Design of Existing Code。
在许多情况下，一开始就选择MVC架构是很有意义的，例如你的应用程序是为广泛的企业应用而设计
的，或者在几年内，你的应用程序可能扩展到一个相当高的流量。 设计一个MVC架构需要有深谋远虑。
大多数程序员发现写逻辑脚本或JavaBeans，以及用HTML显示很轻易。当你设计一个MVC架构时，你必须
首先进行一个完整的设计。这就意味着，分析需要处理的请求的类型，确定哪些组件（JavaBean、数据
库或其它servlets）将处理这些请求，以及对那些请求的回应是如何显示给用户的。 该设计的要害就
是请求和数据的流动性。为MVC架构设计应用程序组件只是对你现在用JSP和servlets所做工作的扩展。
面临的挑战就是构建一个servlet，它接收请求并把那些请求分到应用程序的不同的组件。将一个数据
库请求传送到一个数据库，或将一个处理请求传送到一个JavaBean是很轻易的，但是假如一个请求包含
这两种元素，会怎样呢？或者假如请求的性质在一些处理出现前不能确定，又怎样呢？
Struts 构架
该挑战使我们又回到Struts构架。Struts提供了一个实现MVC架构的高度自动化的方式。它的结构实现
了MVC，并包括一个控制器servlet、一组JSP页面和应用程序的商业逻辑。控制器将用户请求打包，并
把它们导向架构中的其他对象。
Struts构架是围绕一个ActionMapping 结构的。控制器用 ActionMapping 把HTTP消息形式的用户请求
转换成应用程序的动作。ActionMapping指定请求的路径、计划处理请求的对象以及任何服务该请求需
要的其它信息。ActionMapping创建了一个 Action 对象来处理请求。一旦Action对象完成了一个任
务，它就通过在一个JSP页面上写结果来直接回应一个用户请求，或者它可以让一个应用程序流动到其
它地方做回应。
