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