运用你的Strut

了解MVC架构对于用Struts构建的强大的Web应用程序很重要


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页面上写结果来直接回应一个用户请求，或者它可以让一个应用程序流动到其它地方做回应。

下个月，我将讲述一下将MVC模式用于Struts构架的细节问题。然后，我将用Struts来设计和实现一个Web应用程序，该程序将servlet控制器作为计划执行用户请求的Action对象的“调度”基础。

关于Struts构架的更多信息，请参阅Tim Holloway写的封面文章"Struts: a Solid Web-App Framework"。