Java 版 (精华区)

发信人: sgq (小泉叮咚), 信区: Java
标  题: Enterprise Java JSP还是Servlets
发信站: 哈工大紫丁香 (Mon Sep 10 08:44:08 2001) , 转信

Stephen Petschulat（IBM太平洋发展中心） 

自从引入JSP技术，使用Java构建的Web应用服务器端出现了两种架构，第一种是只使用JS
P，第二种是同时使用JSPs和Servlets，以下称之为模型一和模型二，它们分别有各自的优
缺点。近来模型二风行，不仅在网络中有很高的占有率，而且在商业杂志中也备受推崇。
实际上，很多开发者错误的认为这种架构已经取代了模型一并且是使用JSPs的正确方法。
 
 
正确的使用JSPs的方法取决于你目前项目的实际需求，而不是追赶潮流。在这篇文章中，
我将描述这两种架构，权衡利弊，告诉你一些基本的准则来帮助你决定哪一种技术更适合
你。 
 
JSPs提供了一种上乘的解决方案来应付早期的CGI和Servlet面临的问题：你把HTML放在哪
里？几乎对于所有的Web系统，都是使用System.out.println()来输出HTML，导致HTML的改
变需要重新编译。JSPs改变了这种状况，它允许将Java嵌入到HTML中而不是将HTML嵌入到
Java中。只是改变HTML，就不需重新编译（尽管编译是由Web Server自己执行的）。 
 
最直观的使用JSPs的方法就是通过嵌入Java和一些特殊的标签（tag）来达到动态HTML的效
果，就像在其它的Web环境中使用ASPs和ColdFusion。对于一些小的应用，这种方法可以很
好的工作；但是，随着应用的发展和页面变得越来越复杂，这将会导致难以管理。 
 
尽管这是最简单的一种方法，但是很多开发者会发现他们的程序很快就会失控。现在有很
多项目里，JSPs比起一般的Java程序要更加难以调试。很多Web Server会在内部由JSPs生
成Servlets，然后再编译。如果你的JSP存在语法或其它错误，这将会导致编译失败和得到
一个很长的关于那些系统自动生成的代码的无用的编译错误列表。 
 
随着工具软件的改善，我们期待它会对JSPs进行进一步的解析并且给开发者提供更好的调
试信息。尽管这样，对开发者来说，最好还是尽可能的减少JSPs中的Java代码。再者，除
了调试问题以外，一个好的设计思想是尽可能的将页面显示和商业逻辑处理分开。 
 
很多开发者通过使用JSPs与JavaBeans技术的结合来完成将页面显示和商业逻辑处理分开，
这就是实际上被称为模型一的架构（见图一）。JavaBeans用来处理数据对象和商业逻辑对
象，将主要的 Java代码从JSP中移到JavaBeans中可以解决刚才列举的一些问题，所以我们
推荐一般项目使用这种方法（非常简单小项目的除外）。从应用发展的角度来讲，这样可
以保证你的代码调试、测试和管理都比较容易。 
 
 
（图一： 模型一JSP架构） 
 
为了更进一步的将视图（view，显示）部分分离出来，可以将用于显示逻辑的对象封装起
来以格式化你的JSP。这些对象依次同域模型（domain model）进行交互。这特别适合于一
些需要将数据表格化的复杂的JSPs。这将有很多种变化，在一个要与后端EJBs交互的多层
Web应用中，很有用的就是有一个由EJB周围的Bean组成的外层（wrapper）来处理RemoteE
xceptions和其它代表JSP的异常（Exception）。 
 
MVC使用JSPs和Servlets 
当JSPs刚推出时，人们只是认为它是Microsoft的ASPs的直接替代品。但当开发者开始体验
JSP 所带来的新特性时，他们很明显得发现JSPs提供了比ASPs更加有深度的灵活性。由于
与Servlets 的集成，使得在利用Servlets来控制应用程序时，使用JSPs作为模板（templ
ates）成为可能。 
 
模型二架构基本上是基于模型视图控制器（MVC, Model-View-Controller）的设计模式（
见图二）。Servlet充当控制器的角色，它接受请求，并且根据请求信息将它们分发给适当
的JSP来产生响应。Servlet控制器还根据JSP视图的需求生成JavaBeans的实例并输出给JS
P环境。JSP视图可以通过直接调用方法或使用Usebean自定义标签来得到JavaBeans中的数
据。模型二架构在Sun的 J2EE蓝本（Blueprints）中有详细的描述。 
 
 
（图二： 模型二JSP架构） 
 
模型二架构有很多中变化，很多开发者需要首先解决的是：对于整个应用程序，是使用单
一的 Servlet还是很多个。 
 
在一个极端的案例中，整个应用程序只使用一个Servlet，这个Servlet通常的角色就是看
门人（Gatekeeper）和完成重定向的功能（re-director）。看门人的功能是提供公共服务
，比如说身份认证（authentication）、授权（authorization）、登录、错误处理等等。
重定向是Servlet的控制器功能。根据用户的输入，它可充当状态机（state machine）或
分发事件给适当的类来处理请求。这种方法的优点就是在中心点来控制公共服务，但是随
着应用的增长会有一定的风险性。 
 
另一方面，你可以使用Case方案用不同的Servlet来完成不同的功能。这样做时，通常有一
个基础的Servlet，所有的功能Servlet都由这个Servlet继承而来，它处理基本的服务，比
如授权和登录。每一个Servlet只是提供用来完成它本身需求的逻辑功能。 
 
是选择使用以上的一者，还是两者结合，要根据你的具体应用而定。对于很多应用，每一
个数据库的读写是独立的，是可重用的。对于另一些应用，子系统提供很多逻辑上的分散
。在其它项目中，使用Case方案可以指导你如何模拟Servlets。 
二者结合 
模型一和模型二各有优缺点，对于Web的开发者和设计者来说，直接使用JSP是很直观的，
但随着代码的增多会使JSP页面负重不堪。通常，这些代码是有关商业逻辑，是和显示无关
的，最好放在内部对象中。软件工程师经常会倾向于使用MVC模型二来把Web界面从域模型
中分离出来。 
 
尽管模型一很直观，但调试困难。使用Servlet控制器，大多数的商业逻辑在从JavaBeans
传给JSP 之前就已经调试通过了。 
 
无论你使用模型一还是模型二，这里有一些对你有益的惯例。第一个就是将商业逻辑（和
一部分显示逻辑）从JSPs和Servlets中分离出来。这对于系统的可重用性、可维护性和单
元测试都是有好处的。特别是最后一点，因为JSPs和Servlets的单元测试很困难。通过将
商业逻辑放入商业对象和将复杂的显示逻辑放入显示对象，进行编写和执行单元测试时就
容易多了。 
 
如何决定 
如何选择这两种模型没有什么公式化的规则，但有一些很有用的原则和概念来帮助你做选
择那一种更适合你。我们只是介绍广义的理论来说明哪些是最好的惯例。对于所有的设计
和架构模式来说，很重要的一点就是“上下文”（context），只有你根据你的项目的上下
文联系才能决定什么是最好的解决方案。 
 
这两种架构的最明显的区别就是模型一是以“页面为中心"的（page-centric），而模型二
是以"程序为中心"的(programming-centric)。如果你正在开发一个典型的Web应用，只是
页面之间的链接，那模型一是比较适合的。但如果每个链接或按钮背后需要大量的处理后
才能决定下一步要显示什么，那Servlet/JSP MVC是比较适合的。 
 
另一种方法是看你的应用是面向“请求”的还是面向“响应”的。Servlets是面向“请求
”的， JSPs则更加是面向“响应”的，因为JSP页面将HTML的响应发送给浏览器。如果你
的HTML代码要大大多于Java（或者说只有非常少的逻辑来决定要显示给用户什么），那么
模型一就更加适合。 
 
有一个小技巧就是观察请求与响应之间的映射关系，如果对于每一个的请求，只有一个响
应，那么使用Servlet就意义不大。Sun的J2EE蓝本中是这样描述Servlet控制器的：“基于
用户的请求和模型命令的输出，控制器选择一个视图来作为响应的一部分”。如果请求和
响应是一对一的，那么就没什么必要使用控制器。 
 
另一方面，如果每个请求会导致比较复杂的逻辑运算，并且可能返回的视图也不相同，那
么使用 Servlet来做出决定和重定向视图就比较理想。如果你的应用需要支持不同的显示
格式，例如在同一个通道中使用HTML和XML，那这一点就尤其重要了。Servlet能包含逻辑
，来决定客户端是什么，基于这一点来返回不同的文档格式。 
 
在做出决定时，还应当考虑到开发者的技能水平。举例来说，如果应用系统主要是由网页
设计开发人员来维护，而不是软件工程师，那么这可能就是在你做出决定时的关键因素了
。一个上乘的，灵活的，结构巧妙的应用程序，如果继承者无法维护，那就没什么意义了
。 
 
最后，记住模型一和模型二是不能并存的。如果适合你的需要，你可以总是选择使用模型
一或模型二。当结合使用这二者时，唯一要考虑的就是你的项目或组织内部结构连贯的重
要性。如果这不是主要因素，无论是因为开发者的技能水平，还是将应用系统分割成不同
的功能部分的能力，那就没有技术上的原因来使这二者不能共存。 
 
需要说明的一点是，认真考虑如何命名你的URLs和它们指向哪里非常有用。经常是“主Se
rvlet” 
指向没什么意义的URLs。你可以用一个简单的字符串来指定整个互联网中的任何资源，这
个概念看似简单，却意义深远。实际上，这个概念是页面后面的精髓。要确保你的URLs指
向有意义的资源，这样才不会随着时间的流逝而被遗忘。 
 
想象一下，如果在你之前的开发者已经将应用系统划分设计为不同的功能模块，那么你的
工作该是多么的简单。 
 
结论 
这两者（模型一和模型二）在学习和使用过程中都比较简单，如果你选择了不适当的模型
，就会导致系统不够灵活的难以维护，权衡使用它们非常重要。如果有疑问时，可以用一
个简单的项目来试试，以便更好的理解。在软件开发领域跟着流行趋势是很简单的－即使
有时这并不是最佳的解决方案。学习不同的解决方案，自己想想哪一个才适合你的项目，
这才是最好的办法 




--

※ 来源:．哈工大紫丁香 http://bbs.hit.edu.cn [FROM: 202.118.245.178]