Web应用程序框架概述
SunJava™StudioEnterprise72004Q4
SunMicrosystems,Inc.
文件号码：819-1289-102004年12月修订版A请通过/hwdocs/feedback提交有关本文档的意见和建议
版权所有©2004SunMicrosystems,Inc.,4150NetworkCircle,SantaClara,California95054,
U.S.A.保留所有权利。
该发行版本中可能包含由第三方开发的内容。
Sun、SunMicrosystems、Sun徽标和Java是SunMicrosystems,Inc.在美国和其他国家/地区的商标或注册商标。
所有SPARC商标的使用均已获得许可，它们是SPARCInternational,Inc.在美国和其他国家/地区的商标或注册商标。
标有SPARC商标的产品均基于由SunMicrosystems,Inc.开发的体系结构。
UNIX是X/OpenCompany,Ltd.在美国和其他国家/地区独家许可的注册商标。
本服务手册所介绍的产品以及所包含的信息受美国出口控制法制约，并应遵守其他国家/地区的进出口法律。
严禁将本产品直接或间接地用于核设施、导弹、生化武器或海上核设施，也不能直接或间接地出口给核设施、导弹、生化武器或海上核设施的最终用户。
严禁出口或转口到美国禁运的国家/地区以及美国禁止出口清单中所包含的实体，包括但不限于被禁止的个人以及特别指定的国家/地区。
本文档按“原样”提供，对所有明示或默示的条件、陈述和担保，包括对适销性、适用性和非侵权性的默示保证，均不承担任何责任，除非此免责声明的适用范围在法律上无效。
目录 前言5
1.Web应用程序框架概述11简介：构建Web应用程序的挑战11构建Web应用程序：J2EE以前11构建Web应用程序：J2EE以后12J2EE应用程序框架的出现12企业应用程序框架的标准13Web应用程序框架的概念14概述14Web应用程序框架的适用对象15Web应用程序框架的功能15Web应用程序框架定义的补充15Web应用程序框架的工作原理16设计模式的使用16功能的类型17Web应用程序框架与其他Web应用程序框架的区别20基于J2EE标准20一个常见的范例20应用程序一致性20
3 对称显示/提交处理21正式的模型实体22应用程序事件23分层视图和组件范围24高效的对象管理25支持并行内容25易于使用的高级功能26工具准备27企业级性能27小结28
2.Web应用程序框架设计和体系结构的常见问题29Web应用程序框架的适用对象？29拥有J2EE后，为什么还要使用Web应用程序框架？30难道Web应用程序框架不仅仅是另一个专用Web应用程序框架(JAPWAF)吗？30Web应用程序框架与其他J2EE框架有什么不同？31Web应用程序框架具有显示字段概念。
这不同于我所见过的J2EEBlueprints或其他J2EE体系结构-为什么不直接从HelperBean中取值？32Web应用程序框架应用程序需要使用EJB吗？34Web应用程序框架应用程序是如何构造的？34如何实现请求流程和URL格式？35如何将视图Bean与会话或实体Bean关联起来？35将JSP范围设置为请求来简化线程安全编码并在每次请求时强制构造并破坏Bean，这会有负面的性能影响吗？35 索引37 4Web应用程序框架概述•2004年12月 前言 《Web应用程序框架概述》概要介绍了Web应用程序框架并针对其概念、工作原理以及如何与其他的Web应用程序框架进行区分等内容展开讨论。
阅读本书须知 在阅读本书之前，您应该熟悉利用现有J2EEWeb技术，例如servlet和JavaServletPages™（JSP™pages）生成Web应用程序时所用到的概念。
下列资源可提供更多信息：■《Java2PlatformEnterpriseEdition规范》 #platformspec■《J2EE教程》 /j2ee/tutorial■《JavaServlet规范2.3版》 #specs■《JavaServerPages规范1.2版》 #specs 注--Sun对本文档中提到的第三方Web站点的可用性不承担任何责任。
对于此类站点或资源中的（或通过它们获得的）任何内容、广告、产品或其他材料，Sun并不表示认可、也不承担任何责任。
对于因使用或依靠此类站点或资源中的（或通过它们获得的）任何内容、产品或服务而造成的或连带产生的实际或名义损坏或损失，Sun概不负责，也不承担任何责任。
5 本书的组织结构 第1章，第11页上的“Web应用程序框架概述”，概要介绍Web应用程序框架。
第2章，第29页上的“Web应用程序框架设计和体系结构的常见问题”，为初次使用Web应用程序框架的人员提供了有关Web应用程序框架设计及体系结构的常见问题解答。
排版惯例 字体 AaBbCc123 AaBbCc123AaBbCc123 AaBbCc123 含义 命令、文件和目录的名称；计算机屏幕输出 键入的内容，以便与计算机屏幕输出相区别书名、新词或术语以及要强调的词 命令行变量；用实际的名称或值替换 示例 编辑.cvspass文件。
使用DIR列出所有文件。
Searchplete. >loginPassword: 请阅读《用户指南》中的第6章。
这些称为类选项。
必须保存您的更改。
要删除文件，请键入DELfilename。
相关文档 JavaStudioEnterprise文档包括AcrobatReader(PDF)格式的书籍和教程、发行说明、联机帮助以及HTML格式的教程。
访问联机文档 访问SMWeb站点，或者通过SunJavaStudioEnterprise开发人员资源门户(/jsenterprise/)的文档链接，可以查看该部分所描述的文档。
6Web应用程序框架概述•2004年12月 您可以通过上的Web站点()，阅读、打印和购买SunMicrosystems手册。
■《SunJavaStudioEnterprise7发行说明》-文件号码819-1303-10 介绍最新的发行更改和技术说明。
■《SunJavaStudioEnterprise7安装指南》（PDF格式）-文件号码：819-1301-10 介绍如何在每台支持的平台上安装SunJavaStudioEnterprise7集成开发环境(IDE)，包括其他相关信息，例如系统需求、升级指导、服务器信息、命令行开关、已安装的子目录、数据库集成以及有关如何使用“更新中心”的信息。
■《构建J2EE应用程序》-文件号码819-1299-10描述如何将EJB模块和Web模块组装到J2EE应用程序中，以及如何部署和运行J2EE应用程序。
■Web应用程序框架文档（PDF格式）■《Web应用程序框架组件编写人员指南》-文件号码819-1285-10 介绍Web应用程序框架组件体系结构以及设计、创建和分发新组件的过程。
■《Web应用程序框架组件参考指南》-文件号码819-1287-10 介绍Web应用程序框架库中可用的组件。
■《Web应用程序框架概述》-文件号码819-1289-10 介绍Web应用程序框架及其概念、工作原理以及与其他应用程序框架的区别。
■《Web应用程序框架教程》-文件号码819-1291-10 介绍使用Web应用程序框架工具生成Web应用程序的机制和技术。
■《Web应用程序框架开发人员指南》-文件号码819-1293-10 提供创建和使用应用程序组件的步骤（这些应用程序组件经组装后通过Web应用程序框架可用来开发应用程序），并解释如何在大多数J2EE容器中部署该应用程序。
■《Web应用程序框架IDE指南》-文件号码819-1295-10介绍SunJavaStudioEnterprise72004Q4IDE的各个部分，着重介绍用于开发Web应用程序框架应用程序的可视工具的使用。
■《Web应用程序框架标记库参考》-文件号码819-1297-10概要介绍Web应用程序框架标记库，并对该库中可用的标记进行综合引用。
教程 SunJavaStudioEnterprise7教程可以帮助您了解IDE的功能。
每个教程都提供技术和代码样例，您可以在开发大量的应用程序时使用或进行修改。
所有的教程都采用SunJavaSystemApplicationServer来解释部署。
前言
7 所有教程都可以通过开发人员资源门户中的“教程和代码库”链接进行访问。
在IDE中选择“帮助”>“示例和教程”可以访问到所有这些教程。
■快速入门指南概要介绍了SunJavaStudioIDE。
如果您初次使用SunJavaStudioIDE或者希望获取某个特定功能的快速介绍，请首先访问快速入门教程。
这些教程描述了如何开发简单的Web应用程序和J2EE应用程序、生成Web服务；如何开始进行UML建模和重构。
您只需花几分钟的时间便可以了解快速入门教程。
■教程着眼于SunJavaStudioIDE的单一功能。
如果您希望了解某项特定功能的详细信息，请尝试使用教程。
取决于示例的着眼点，有些教程从头开始生成应用程序，有些教程则是在提供的源文件上构建应用程序。
您可以花一个小时或更少的时间完成该教程。
■解说式教程利用视频来说明某项功能或技术。
请尝试使用解说式教程，获取关于IDE的可视化概述或某项特定功能的进一步说明。
您只需花几分钟的时间便可以完成解说式教程。
此外，您还可以随意启动和停止解说式教程。
联机帮助 您可以在SunJavaStudioEnterprise7IDE中获得联机帮助。
通过按下帮助键（MicrosoftWindows环境中为F1，Solaris环境中为Help键），或者选择“帮助”→“内容”可以打开帮助。
执行以上任意操作都将显示一个帮助主题列表和一个搜索工具。
使用易读格式的文档 该文档以易读格式提供，以方便残障用户使用辅助技术进行阅读。
您还可以按照下表所描述的信息找到文档的易读版本。
文档类型 书籍和教程教程 发行说明 易读版本的格式和位置 HTML格式，位置： HTML格式，位置：开发人员资源门户(/jsenterprise)的“示例和代码库”链接 HTML格式，位置： 8Web应用程序框架概述•2004年12月 Sun欢迎您提出意见和建议 Sun致力于提高文档质量，并欢迎您提出宝贵的意见和建议。
请通过电子邮件将您的意见发送至以下地址：docfeedback@请在电子邮件的主题栏中注明书名（《Web应用程序框架概述》）及其文件号码(8191289-10)。
前言
9 10Web应用程序框架概述•2004年12月 第1章 Web应用程序框架概述 本章概要介绍了Web应用程序框架，包括以下章节：■简介：构建Web应用程序的挑战■Web应用程序框架的概念■Web应用程序框架的工作原理■Web应用程序框架与其他Web应用程序框架的区别■小结 简介：构建Web应用程序的挑战 构建Web应用程序：J2EE以前 由于J2EE™解决了第一代Web开发人员面临的核心问题，因此，J2EE，尤其是其Web层组件（Servlet和JSP）已经非常成功。
在J2EE出现以前，这些开发人员在构建简单的应用程序时都必须对付大量不同的编程模型、API和各种不同的服务器。
由于选择能满足应用程序要求的技术，就必须得考虑各种庞杂的因素，因此要构建企业规模的应用程序就变得更加困难。
实际构建一个应用程序是另一个棘手的问题，而平台不成熟、API不匹配、跨平台集成问题和缺乏高度可伸缩的开发和维护模型使这个问题变得更加复杂。
尽管服务器供应商通过提供功能强大的高级应用程序框架解决了大量编程和开发可伸缩性问题，但是在这些框架中，只有少数几个框架基本假定可以通用，而通用协议或框架结构并不能真正通用。
这些框架通常连接至服务器供应商的专用服务器框架结构，尽管它们有可能构建功能强大的、强健可靠的企业应用程序，但无法更改供应商或者简便地利用由其他供应商提供的技术。
如果不重写应用程序，则实质上无法实现从一个供应商的平台转移至另一个供应商的平台。
11 企业设计师采用了几种策略以避免这种供应商封锁，最普遍的策略就是在体系结构中增加大量抽象内容。
尽管此策略解决了某些问题-可以使企业业务对象和进程从Web容器细节中分离-但是又产生了其他问题。
这些抽象内容大大增加了应用程序的复杂性，不可避免地给开发和部署带来了困难。
设计师越是试图远离专用API时，调试此复杂框架结构就越困难。
由于每一个新项目都会带来新的体系结构和约束，可能与开发人员先前遇到的体系结构和约束不兼容，因此Web开发人员的技能变得越来越不能重复使用。
每一个应用程序都自成一体，缺乏必要的一致性，当基础应用程序框架没有为开发人员和设计师提供有力的指导时，这种情况尤其严重。
尽管某些约束有助于专注应用程序开发工作，但某些框架如此高级，以致开发人员必须融合各种功能以完成高级的（在某些情况下是例行的）任务。
构建Web应用程序：J2EE以后 J2EE的出现解决了第一代Web应用程序开发所特有的许多问题。
开发人员第一次可以依赖容器及其应用程序组件之间的标准协议，并保证所有J2EE兼容的容器都提供相同的精心设计的API。
设计师和开发人员可以从纷繁复杂的专用框架、API和容器中解脱出来。
但是，自由是有代价的。
尽管J2EE是应用程序框架的坚实基础，但是它本身并不稳固。
J2EE规范未采用应用程序开发领域的建议做法。
J2EE将设计（或采用）一个满足应用程序开发需要的应用程序框架结构的主要任务留给了设计师和开发人员。
J2EE不能独自完成此项任务。
J2EE应用程序框架的出现 要开发现实世界的应用程序，特别是大规模的企业Web应用程序，开发人员必然会发现他们必须创建某种框架。
J2EE提供了针对Web的基本平台，但是实际应用程序开发所需的其他内容必须由其他软件提供，而在内部开发一个框架可能既费时又容易产生错误。
因此，已出现大量建立在J2EE之上的可重复使用的（可重复使用性并不高）Web应用程序框架，每一个框架都试图满足某一范围内的开发人员的需求。
例如，某些框架专门处理输出到客户端的数据的显示，而其他框架则处理输入数据的验证。
还有一些框架试图将胖客户端和瘦客户端的GUI开发统一起来。
由于J2EE废除了在第一代Web应用程序开发过程中使用的实际体系结构，每一个J2EE项目现在必须评估和选择一个适合自身要求的最佳应用程序体系结构。
通用概念和术语已逐步形成，以帮助讨论这些体系结构（其中的示例包括类型I和类型IIServlet体系结构、服务到工作者委托以及基于MVC的UI）。
尽管这些概念都很基本、很重要，可以广泛应用于从非常小到非常大的各种应用程序。
但是，这些概念都没有真正提供如何以一种可重复、可维护和可伸缩的方式构建Web应用程序的细节。
12Web应用程序框架概述•2004年12月 为了强调最后这一点，几乎所有同时期的应用程序框架都要求使用类型II、服务到工作者和基于MVC的体系结构，然而，这些框架在实现、可扩展性以及其对开发人员设置的约束方面存在明显差别。
知道基本的体系结构仅有助于开发人员了解该框架。
它在帮助开发人员学习该框架，或甚至将其与其他框架进行比较时（特别是当这些框架针对不同的应用程序规模时）所起的作用都非常小。
并非只要具有足够的术语，就能有效地描述现代框架的功能。
因此，需要更加详细的分析以真正理解一个框架向另一个框架提供的内容，特别是框架向企业应用程序开发提供的内容。
仅按照功能检查表工作是明显不够的。
企业应用程序框架的标准 依靠经过测试和已获证明的体系结构，构建Web应用程序的过程中要比在其他应用程序开发领域中重要得多。
例如，在响应不是最适合的体系结构或技术选择时，胖客户端应用程序的承受能力相对较强。
当完全拥有自己的新型工作站时，即便最抽象的客户端应用程序体系结构也都将能满足性能上的要求。
当必须通过松耦合的网络在共享硬件（此硬件同时支持几百或几千个用户）上运行相同的应用程序时，这种情况根本不会出现。
在这种领域中，错误选择体系结构或技术，所导致的差别往往是：要么以及时的方式响应请求、要么根本不响应请求；或者要么能较好调节开发和生产、要么仅完成其中一项任务而不能完成两项任务。
在中小型应用程序开发领域中，某些因素导致的故障是可以原谅的，因为这里少量开发人员完全致力于一个应用程序。
在这种情况下，由于将来更改的范围以及与其他项目组接触的范围有限，因此体系结构可能会更加容易修改；并且当出现问题时，项目组成员可以轻松地协调解决。
可以轻松地共享编码标准和最佳方法，更新应用程序的陈旧部分仅需要几个小时的工作。
项目组往往具有相似的专业水平，可以保持稳定、长期合作。
由于这些应用程序的用户群体较小或容许较慢的响应时间，因此性能通常不是关键因素。
企业应用程序的开发与中小型应用程序的开发模型相比，结果正好相反。
项目组之间的通信很难；更改应用程序会产生较大的影响；最佳方法很少能够传播到子项目组之外；更新应用程序的某些部分简直是不可能；开发人员的流动性大；开发人员的专业变化范围很广。
最后，性能是绝对关键的，因为性能可能在用户决定是继续使用还是摒弃该应用程序时起着决定性的作用。
相对于易用性而言，用户可能更希望应用程序具有更及时的响应。
因此，辅助企业Web应用程序开发的任意框架必须在其设计和实现中解决这些约束。
更重要的是，它必须使这些约束对应用程序开发工作的影响降低到最小程度，甚至在理想条件下消除影响。
因此，任何企业框架都必须完成以下工作：■提供应用程序一致性，从而可以在不同的项目组、项目以及公司之间复用开发人员 的技能。
开发应用程序应该很容易入门，但是不应该限制开发人员的能力。
■提供高级和低级功能，使项目组可以找到满足其需求的真正平衡并在限制时间内完 成项目。
第1章Web应用程序框架概述13 ■提供可用来提高应用程序可维护性的具体方法（以可以想到的各种不同方式），使设计师和开发人员不必自己完成这项工作。
■对那些没有经验的开发人员进行指导，因为并非所有的开发人员天生就具有相同的能力，某些开发人员可能在基于Web的应用程序领域中缺乏经验，甚至缺乏企业开发领域的经验。
■为高级开发人员提供辅助工具，以便他们直接使用基础的J2EE平台创建高级功能，而无需在框架功能上浪费时间。
■向企业设计师求助，让需要合并的高级体系结构要素可以立即用于框架或与框架兼容。
企业设计师应该适应框架谨慎选择体系结构的方式，最好他或她会对资源做出同样的选择。
最重要的是，在企业设置中，框架必须是经过证明的、成熟的、强健可靠的并且性能良好。
框架的用户必须知道期望得到的结果，在开始任何开发工作之前，他们必须确保框架能够满足这些要求。
本章的其余部分介绍了要成为真正的企业类Web应用程序框架的Web应用程序框架应该如何处理这些问题以及如何满足这些条件。
Web应用程序框架的概念 概述 Web应用程序框架是基于标准的成熟且功能强大的J2EEWeb应用程序框架，它适用于企业Web应用程序的开发。
Web应用程序框架融合了一些常见概念，例如显示字段、应用程序事件、组件分层结构和以页面为中心的开发方法，并使用基于“模型-视图-控制器”模式和“服务到工作者”模式的最新设计。
Web应用程序框架建立在行业中领先的软件工程师、顾问、Web应用程序开发人员和企业Web设计师的集体经验的基础之上。
从2000年1月起，Web应用程序框架已处于开发中，到2000年6月开始投入使用。
从那一时刻起，Web应用程序框架已用于许多现实世界的企业Web应用程序中，并成功地用于支持数百万用户以及每天数百万美元金融交易量的站点。
14Web应用程序框架概述•2004年12月 Web应用程序框架的适用对象 Web应用程序框架主要用于满足要构建中型、大型和超大型Web应用程序的J2EE开发人员的需要。
尽管Web应用程序框架可以并且已经用于小型Web应用程序，但其主要的优点在这种规模下并不十分明显。
当应用程序经过长期维护、经历了许多更改并在其范围内不断发展时，Web应用程序框架会变得格外出色。
简而言之，Web应用程序框架在帮助开发企业应用程序方面表现突出。
由于Web应用程序框架为可重复使用的组件提供了核心设备，因此它非常适合于要提供可轻易集成到Web应用程序中的现成组件的第三方开发人员。
特别值得一提的是，由于这些扩展功能为最终用户和最初的开发人员都提供了一个定义良好的方法，用以扩展和利用现有的垂直划分功能，所以这些相同的功能使得Web应用程序框架非常适于作为构建垂直划分Web服务的平台。
Web应用程序框架的功能 Web应用程序框架使用含有最新技术的J2EE设计模式，帮助开发人员构建企业Web应用程序。
它提供了一个基于设计模式的、企业设计师可以将其体系结构的其他部分附着在上面的框架。
Web应用程序开发人员会发现这是一种简单的开发方法；企业设计师会发现这是一种描述清晰的设计模式，该设计模式以明确定义的方法与其他企业层和企业组件进行集成。
Web应用程序框架为开发人员提供低级和高级框架结构、设计模式以及完整的组件模型，帮助他们构建可重复使用的组件。
开发人员定义的组件是与Web应用程序框架进行交互操作的最好对象，就好像这些组件是本地组件一样。
可以在应用程序中、跨应用程序以及跨项目和公司任意组合和重复使用组件。
最后，Web应用程序框架还可以引导新的J2EE开发人员熟悉Web应用程序开发，并通过向高级J2EE开发人员提供一个强大的工具箱，让他们能够开发出通过其他框架无法开发的高级功能。
Web应用程序框架定义的补充 Web应用程序框架不是一个企业层框架，这意味着它不会直接帮助开发人员创建EJB、Web服务或其他类型的企业资源。
尽管Web应用程序框架适用于企业应用程序开发，但它实际上是这些企业层资源的客户端，因此提供了访问这些资源的正式且最佳的机制。
第1章Web应用程序框架概述15 Web应用程序框架的工作原理 设计模式的使用 Web应用程序框架是建立于行业可以接受的、最新设计模式和技术的基础之上，作为一个J2EE表示层框架，它实现了JavaSoft发布的J2EE核心模式并严格依赖于它。
下表列出了Web应用程序框架所使用的已发布的J2EE设计模式。
拦截过滤器 拦截过滤器 前台控制器复合视图 视图帮助器分发程序视图服务到工作者业务委托会话虚包 服务定位器值列表处理器 复合实体传送对象汇编程序传送对象服务激励器数据访问 对象 表示法 表示法 表示法表示法表示法表示法 表示法 表示和业务业务业务业务 业务业务 业务集成集成 J2EE核心模式（请参阅/blueprints/corej2eepatterns/index.html）
X JavaBluePrints模式目录（请参阅/blueprints/patterns/catalog.html）*
X X
X X
X X
X X
X X
X X
X X
X X
X X
X X
X X
X X
X Web应用程序框架执行 Servlet2.3过滤器XXXX
X X****** **** ****
X 16Web应用程序框架概述•2004年12月 拦截过滤器 快速道读取器模型-视图控制器 适配器 命令 表示法 表示法全部(A)表示法 J2EE核心模式（请参阅/blueprints/corej2eepatterns/index.html） JavaBluePrints模式目录（请参阅/blueprints/patterns/catalog.html）*
X Web应用程序框架执行
X X
X XX *注意：J2EEBluePrints样例应用程序（例如PetStore）实现了许多业务层和集成层模式，但是仅作为这些模式的演示才有效。
而且，许多这些模式都被指定使用J2EEBluePrints应用程序所采用的EJB。
但是，Web应用程序框架对其一无所知。
由于各种原因，Web应用程序框架在某些特定的情况下提供了EJB使用的替换方法，这些替换方法从Web层实体使用业务层和集成层的某些模式。
**Web应用程序框架至少实现了J2EE表示层模式，但是，像只有表示层框架所期待的那样，Web应用程序框架不需要实现业务层和集成层模式。
这些模式的大多数可以作为向企业层和集成层开发人员推荐使用的最佳方法，这些模式是完全兼容的并且可以与该框架的表示层模式相集成。
除了使用上面列出的模式之外，Web应用程序框架还建立在多层JSP/Servlet体系结构的基础之上，并完全围绕反映这些模式的接口和对象协议进行设计：首先它是一组集成的协同设计模式，然后它是这些模式的一个实现。
在Web应用程序框架的模式中，最主要的是模型-视图-控制器(MVC)模式。
尽管其他框架也声称是MVC框架，但实际上它们通常着重于该模式组件的一个（也许是两个）组件，但很少着重于所有三个组件。
此外，其他框架通常声称JSP（也许使用一个定制标记库）包含一个完整而正确的视图层。
它们还多次声称针对应用程序的业务对象包含一个完整而正确的模型层。
这些说法并不真实。
Web应用程序框架完整地提供了MVC模式的三个组件。
它使用具体的关系定义正式的视图和模型实体，并提供一个允许应用程序以适当的方式确定控制器逻辑范围的高级逻辑控制器。
Web应用程序框架的视图层整合了JSP技术，但是又与JSP技术不同。
同样，Web应用程序框架的模型层也整合了其他J2EE技术，但是与任何J2EE技术都不同。
由于以上原因以及下面要介绍的其他原因，Web应用程序框架为开发人员提供了其他框架完全不能比拟的可扩展性。
第1章Web应用程序框架概述17 功能的类型 Web应用程序框架功能在逻辑上分为三部分。
■Web应用程序框架核心■Web应用程序框架组件■Web应用程序框架扩展 Web应用程序框架核心 通常将Web应用程序框架核心简称为Web应用程序框架。
它定义了基本的接口、对象协议和原语，还为应用了Web应用程序框架的应用程序提供了所需的最小框架结构。
Web应用程序框架核心不提供组件库，但是可以为组件编写人员提供使能技术。
Web应用程序框架核心包含基于视图的原始框架（例如ContainerView、TiledView和TreeView）以及基于模型的原始框架（例如DatasetModel、QueryModel和TreeModel）。
Web应用程序框架核心也为请求分发和可重复使用的命令对象提供原始框架。
通过使用这些原始框架，开发人员可以轻松地创建针对应用程序的组件或者可以在项目内或不同的项目之间共享的可重复使用的组件。
Web应用程序框架核心也包含使开发人员可以立刻开始构建高性能应用程序的高级功能。
以下各节中包含了这些功能的详细信息。
Web应用程序框架组件 Web应用程序框架组件利用Web应用程序框架核心的框架结构，为应用程序开发提供了高级的、可重复使用的组件。
这些组件风格各异，适用于不同的使用范围。
例如，水平划分的Web应用程序框架组件往往成为最普遍的可用组件，其优点在于灵活并且可以定制。
这些类型的组件可以由许多不同的Web应用程序框架用户群体在不同的项目和公司之间使用，通常不局限于任何特定的外观和功能。
垂直划分的Web应用程序框架组件是为特定使用情况量身定做的，可以提供高级功能和易用性。
这些类型的组件适用范围较窄，但是由于其范围定义明确，这些组件可以最小程度地保持参数化并使用特定的外观和功能。
所有Web应用程序框架组件可以使用由Web应用程序框架核心提供的所有设备，并建立在高级功能（例如WebAction、基于SQL的模型实现和TreeView）的基础上。
Web应用程序框架扩展 最后，Web应用程序框架扩展以一种Web应用程序框架兼容的方式提供对非J2EE设备的访问。
在许多情况下，Web应用程序框架扩展允许在Web应用程序框架应用程序中无缝地使用针对容器的功能。
扩展与Web应用程序框架组件的区别在于扩展着重于技术集成而不是应用程序开发。
18Web应用程序框架概述•2004年12月 技术概述 Web应用程序框架，或更确切地说Web应用程序框架核心是纯粹的Java，并打包为一个行业标准的JAR文件。
Web应用程序框架定义了若干个顶层软件包，如下所示：.jato-请求处理框架结构mand-与命令相关的接口和实现.jato.taglib-定制JSP标记库.jato.model-与常规模型相关的接口和实现.jato.view-与常规视图相关的接口和实现 每一个软件包都包含更加针对派生的子软件包（例如针对HTML的视图实现和针对SQL的模型实现）。
Web应用程序框架组件或Web应用程序框架扩展没有正式的软件包或类，它们是纯粹的逻辑分类。
编写Web应用程序框架应用程序时，开发人员从现有的Web应用程序框架类中派生出针对应用程序的子类，或以一个针对应用程序的方式实现某些Web应用程序框架接口。
在大多数情况下，开发人员将使用现有的Web应用程序框架核心实现作为超类，因此继承了大量有用的操作。
（组件开发人员更有可能直接实现一组Web应用程序框架接口。
） 应用程序对象是围绕某页面的中心概念而组织的。
每一个页面都包含一个显示规范-通常是一个JSP包含静态内容和标记（另外还包括定制Web应用程序框架标记）-一个类包含该页面的根视图分层结构。
每一个对服务器的请求都返回一个页面作为结果。
应用程序的页面流量由开发人员编写的控制逻辑来确定。
除了由开发人员提供的关系之外，在一个页面和另一个页面之间没有固定的关系。
在HTML中，每一个显示页面通常都包含一个或多个用户可以激活的链接或按钮。
每激活一个链接或按钮都会将数据发回服务器，并导致调用针对该激活的命令对象。
此命令对象可以自己采取行动，或将请求的处理委托给开发人员定义的事件方法。
最终，请求将被转发到一个负责对客户端的响应进行显示的资源。
在大多数情况下，此资源是一个基于HTML的、使用Web应用程序框架标记库对动态内容进行显示的JSP页面。
标记库使用Web应用程序框架视图组件来获得其显示的数据。
这些视图对象与一个或多个模型对象相关联，并按照需要从模型对象中提取数据。
因此，Web应用程序框架视图可以充当许多模型的分层虚包。
这些视图可以在多个不同的页面之间通过不同的模型重复使用。
由于模型没有显示相关性或视图相关性，因此通常可以由多个视图使用。
以页面形式接收响应之后，用户可以激活链接或按钮，并向Web应用程序框架应用程序发回一个请求。
该请求将发回到显示页面的相同对象。
此操作允许Web应用程序框架的框架结构将提交的数据映射回其源自的相同视图（和此类模型），并提供该数据虚拟持久性。
开发人员与应用程序对象和提交的数据进行交互式操作，好像中间从来没有一个响应请求循环。
将数据映射回原始对象之后，针对该链接或按钮的命令对象将被激活，循环将再次开始。
第1章Web应用程序框架概述19 Web应用程序框架与其他Web应用程序框架的区别 以下各节概要介绍Web应用程序框架和其他同时期的Web应用程序框架的主要差别。
基于J2EE标准 许多框架将Servlet当作一项切实可行的技术而不使用JSP，反之亦然。
还有某些框架宣称它们采用了这些标准，但是实际上，它们仅仅是可以通过使用基本Servlet级别的集成在J2EE容器中运行的专用容器。
Web应用程序框架直接包含了类似于Servlet和JSP的J2EE标准，同时，开发人员仍然可以自由地使用J2EE提供的功能。
Web应用程序框架不是一个容器内的容器，也不是一个将开发人员从J2EE中抽象出来的分层。
相反，它增强了促进企业Web应用程序开发的J2EE功能，同时开发人员仍然可以按照自己的意愿与J2EE/Web应用程序框架进行交互式操作。
一个常见的范例 Web应用程序框架提供了显示字段、应用程序事件、组件分层结构和以页面为中心的开发方法，所有这些结构都经过了时间的考验并且非常适合于开发人员通过使用Swing、Delphi、VisualBasic或PowerBuilder技术来熟悉客户端应用程序开发。
尽管由于提供的是Web范例而存在差别，但这些常见的结构可以将一种对Web应用程序框架的自然感知传递给开发人员，可以明显加快应用程序的开发。
这也意味着Web应用程序框架特别适合与应用程序生成器（例如ForteforJava或JBuilder）进行集成（要获得有关应用程序生成器集成的更多信息，请参阅工具准备小节）。
应用程序一致性 许多现代Web应用程序框架相当灵活，在某些情况下，这是设计的基本目的。
它们有意识地在应用程序的某些方面（例如其模型层）力求非规范。
相反，它们着重于应用程序设计的一个或两个部分，最常见的是MVC体系结构的控制器和视图部分，而将其余部分留给开发人员。
某些设计师和开发人员可能从来不认为灵活性是一个缺陷，但是当考虑企业开发时，灵活性就可能是一个缺陷。
尽管将灵活性当成一个缺陷开始听起来可能感觉奇怪，但灵活性和应用程序一致性之间存在着对立关系。
具有最大灵活性的框架（例如J2EEAPI自身）可以导致应用程序的开发方式各种各样。
20Web应用程序框架概述•2004年12月 不加限制的灵活性或不确定的开发方向，会让没有经验的设计师和开发人员使用一些似乎可以完成手头任务的技术（或任何技术），即使此技术最终存在缺陷。
当框架不能提供一个在整个开发任务中可以遵循的清晰路径时，开发人员很可能会使用破坏或偏移框架提供的优点的技术。
此外，每一个独立的项目组可能都会使用不同的技术，以致即使在相同的应用程序中，一个组也不能轻易地理解或维护另一个组的工作。
最糟的情况是：在应用程序的某一部分中使用的一项有缺陷的技术会损害应用程序的其余部分，以致应用程序的性能或可伸缩性受到影响。
当一个没有经验的设计师或开发人员为应用程序选择了一个较差的全局方向时，这种情况很有可能出现。
这样一个选择可能导致整个应用程序出现难以处理的体系结构问题，最坏的情况是应用程序最终无法工作。
不幸的是，对于Web应用程序开发人员来说，大多数框架的灵活性在开发和生产中容易产生相反的结果。
如上所述，一个好的企业框架应该以正确的方向引导没有经验的开发人员，而不是以引导高级开发人员的方式来引导他们。
许多框架只实现了后者，这是因为它们在体系结构或应用程序开发的某些方面是不规范的，或者是因为设计原理或设计缺陷，造成这些框架只能做成这样。
项目开始时，开发人员要做出许多选择，包括许多由于没有正确选择而给整个项目带来明显危害的选择。
比较而言，Web应用程序框架为Web应用程序体系结构和应用程序开发提供了一个固有的已经证明的方向，而且不会妨碍其他方法的使用。
通过提供与应用程序进行交互式操作的明确定义的点以及扩展、加强或覆盖现有操作的清晰方式，Web应用程序框架做到了这一点。
使用Web应用程序框架开发Web应用程序和使用其他框架来开发Web应用程序所存在的区别是：刚使用Web应用程序框架的用户不需要做出选择（可能是不好的）便可以开始使用。
该用户从一开始就可以使用一种常规方法，当可以更熟练地使用Web应用程序框架和J2EE之后，其他方法和技术将变得易于理解了。
而且，开发人员此时完成的所有工作仍然可以与后来所使用的更高级的技术保持一致。
其结果是，用Web应用程序框架编写的应用程序比使用其他框架编写的应用程序彼此之间更加相似。
它们在高级和低级功能的使用上都更加一致，因此更易于维护。
对称显示/提交处理 目前许多应用程序框架是从定制标记库发展而来，定制标记库是一种广泛使用的技术。
在某些情况下，这些框架和定制标记库类似，也许还包含一个或两个附加接口。
其结果是，这些框架缺乏长远考虑，严重局限于发送给用户的数据的显示，为处理来自用户的数据所提供的帮助较少。
这些框架也许较好地满足了开发人员某一部分的需求，但这是以牺牲其他部分为代价的。
在类型II体系结构中，提交（请求）周期过程中不包含类似于JSP的显示技术。
这意味着如果视图表示法仅在JSP中定义，则提交周期逻辑不能利用此视图表示法。
该逻辑反而只接收原始参数列表作为输入。
这样，开发人员就只能使用这些值的原始形式，得到的帮助很少或几乎没有。
他们突然进入到最基本的Servlet技术的深处。
通常，这些框架中没有指定应用程序对象之间的清晰关系，因此难以维护。
由于这些框架向输入数据提供较少的结构或根本不提供结构，因此调用的组件不得不在“黑暗”中工作，无法可靠地了解给定的请求调用上所收到的数据内容。
项目开始时，这将给项目带来负担（也许不会很快显露出来），随着应用程序逐渐变大，这些负担将很快成为一个主要因素。
第1章Web应用程序框架概述21 缺少对称显示和提交周期通常会导致对象之间的依赖关系激增。
通常，这种关系的激增反映为低级控制器逻辑的激增，用户需要手动将输入数据转移到目标对象或后端。
它可能会导致一种不对称性：显示页面时使用后端对象或模型，但处理来自先前显示页面的请求时又不直接使用后端对象或模型。
这种不对称性为开发人员微管理后端组件带来了许多负担，并且会造成开发人员忙于处理Web应用程序容器中运行着的低级细节。
在以显示为中心的体系结构中，不能获得较好的生产力和可维护性。
比较而言，Web应用程序框架以对称方式依靠其正式的视图层帮助显示和提交周期。
鉴于其他框架不能精确地将其视图层定义为JSP或某些其他种类的内容显示技术，Web应用程序框架将显示规范(JSP)与视图组件进行了区分。
只有将这些结合在一起才是完整的视图层。
一个Web应用程序框架应用程序主要定义视图组件的分层结构，然后从显示规范中引用这些组件。
在显示和提交周期中，开发人员以相同的方式与这些视图组件进行交互式操作。
视图组件是规范的视图表单。
正式的模型实体 如上一节所述，许多框架过多地关注于帮助向用户提供数据显示的技术。
这类框架最常见的种类是那些着重于XML和XPath的框架。
尽管这些框架可以吸引开发人员使用最新的一流技术，但是这些框架在应用程序提交周期中提供给开发人员的帮助很少，并经常需要以XML格式或某些其他面向显示的格式来表示应用程序数据。
将应用程序数据强制表示为以框架为中心，这项任务比较繁重，某些情况下，这可能是一个致命的缺陷。
相反，Web应用程序框架认为应用程序应该能够以一种视图未知的方式表示其数据，并为获得该数据提供一个正式的机制，无需暗含特别的数据格式。
因此，Web应用程序框架提供了一个正式的模型实体，该实体定义了几个所有模型必须实现的标准方法。
使用一个任意的针对模型的关键字，模型用户（包括Web应用程序框架视图）能够以一种标准方式获得模型数据，无需做出任何有关该模型如何在内部表示其数据的假设。
根据这个原因，Web应用程序框架组件可以按照相同的方式与任何模型进行交互式操作，允许将不同的模型插入到相同的视图。
模型可以互换，因此它们表示的数据也可以互换。
不必纯粹为了显示而将数据处理成特定的格式，视图层无需了解与其进行交互式操作的数据的具体类型。
不同类型的模型可以在一个应用程序中共存，不需要视图层识别其本地数据格式之间的任何差别。
对于模型用户来说，XML/XPath、JDBC、JDO和其他企业数据看起来都是相同的，因此Web应用程序框架可以包含着重于这些数据格式之一的任何框架的开发方法。
最后，在企业层资源上插入模型结构，进一步增加了抽象程度，不但使应用程序设计更加一致，而且显著减轻维护的负担。
在正式定义从企业层获得的数据时，开发人员还需要在应用程序的各个层之间定义一种正式但属于松耦合的协议。
有了这种协议，今后就可以用一种完善的方式轻松地修改应用程序。
出现不利情况的几率会降低，即便出现不利情况，也会很快被识别出来。
22Web应用程序框架概述•2004年12月 应用程序事件 Web应用程序框架向开发人员提供了大量与应用程序相关的事件。
有三种类型的事件：常规请求事件、特定请求事件和显示事件。
常规请求事件包含类似于onBeforeRequest()、onSessionTimeout()和onUncaughtException()的事件。
开发人员可以使用这些事件来响应常规的应用程序和请求生命周期情况（包括错误状态）。
缺省情况下，与错误相关的事件使用一个一致的本地化的机制向用户报告错误，开发人员可以覆盖这些事件以采取针对应用程序的操作。
特定请求事件基于用户的操作发生。
当用户激活页面上的链接或按钮（在Web应用程序框架中也称作CommandField），该请求将导致调用服务器上与该激活操作相对应的命令对象。
在响应这些操作时，尽管用户可以提供他们自己的命令对象，缺省的命令实现将请求的处理委托给表单的请求处理事件方法handleRequest()，此处是用户激活的CommandField的名称。
该事件在CommandField的父容器上调用，因此该事件位于最初显示链接或按钮的组件范围之内。
在此事件处理器中，开发人员可以采取自己喜欢的任何操作，按自己的意愿处理请求，或者将请求的处理委托给另一个对象。
此Web应用程序框架功能与其他Web应用程序框架所提供的类似处理请求功能之间的主要区别在于：此事件在与之相关的组件上被调用，每个链接或按钮都经过仔细设计。
其他框架通常为每个HTML表单只提供一个设计粗糙的事件处理器，并让开发人员基于用户的操作来创建条件代码。
作为字段更改集，这既杂乱又难以维护。
由于每次在表单中添加或删除新的链接或按钮时，都必须更改单个事件处理器，而不管它是否包含在组件中，该方法也会造成使用模块化的、独立组件变得困难（要获得有关此缺陷的更多信息，请参阅分层视图和组件范围小节）。
最后，Web应用程序框架还提供了经过仔细设计的字段级别的显示事件。
显示事件在页面显示的过程中被调用，这让开发人员可以进入通过其他方式几乎不可能实现的显示进程。
从这些事件中，开发人员可以访问标记处理器，也可以访问JSP页面上下文和输出流。
显示事件可以同时用于跳过字段的显示或终止当前显示页面。
它们也可以用于调节由JSP显示的传出内容，并提供高级的内容过滤功能。
此外，显示事件会将与组件相关的显示逻辑封装到该组件内，因此，即使使用高级的显示技术，也可以为组件提供高度的可复用性。
最重要的是，显示事件在JSP之外保留了Java代码或类似于程序的结构。
JSP中任何种类的程序构造通常都存在着维护问题，这不仅是由于它将应用程序功能暴露给JSP制作人员，同时还由于并行内容必须在潜在的许多位置复制此功能（要获得有关并行内容的更多信息，请参阅支持并行内容小节）。
对于需要较少维护或不需要显著维护或生命周期有限的中小型应用程序来说，尽管这些种类的功能可能带来较高的生产率，但这样的应用程序在企业中不具有代表性。
许多框架都强调这种应用程序的开发，众多框架的功能都以使用模仿传统编程语言的各种程序构造来实现这些功能为目标。
比较而言，Web应用程序框架认识到了JSP的优点并加以充分利用，并没有降低可维护性或应用程序开发人员控制JSP显示的能力。
第1章Web应用程序框架概述23 分层视图和组件范围 大多数框架将平面名称空间用于HTML表单中的数据字段名称。
此平面名称空间严重限制了视图组件可以组合的方式。
例如，无法在同一个表单上使用两个名为名称字段的组件。
从全局的角度来看，在所有组件和表单中，唯一的方法是提供所有字段的唯一名称。
很明显，开发过程中此解决方法不会发生变化，并且减少了全局组件市场的开发。
对于依靠紧耦合的表单对象词汇索引的框架来说，情况更糟糕。
在这种情况下，一个HTML表单对应一个Java对象（通常是一个JavaBean），每个表单字段都对应取值方法和赋值方法。
类似于name的简单表单字段名称可以轻易地映射到类似于getName()和setName()的Java方法。
但是，如上所述，如果开发人员想要使用可复用的组件，那么他们几乎不能使用这些简单的名称，而需要使用所提供的全局唯一的名称。
将类似于ponentA.name的复杂字段名称映射到Java方法名称会非常不精确。
这样的名称必须符合Java方法命名标准，因此唯一可行的选项是getCom_ponentA_name()和setCom_ponentA_name()。
也许可以使用，但会不精确或者难以维护。
任何依靠单一对象作为表单字段名称的虚包的框架都会妨碍视图组件的使用-不管是否在多个页面上使用该表单的一部分，所有在该页面或表单上使用的数据都必须由单一的对象接口反映。
开发人员可以创建一个仅由表单使用的对象，然后委托给其他更容易复用的对象，但是这会需要冗长的并且难以维护的数据转移代码，而且这不是一个真正的组件体系结构。
此外，它还需要一个编译步骤以便在表单或页面中进行更改，这是要与应用程序生成器一起工作的框架所存在的一个严重缺陷。
比较而言，Web应用程序框架为没有基于紧耦合的表单对象词汇索引的HTML表单字段提供了一个分层名称空间。
每一个显示字段视图是作为父容器视图的子项而创建的，并在该容器内使用简单的本地名称。
因此，它无疑继承了一个限定的唯一全局名称。
即使本地名称与其他容器中的名称相同，也可以确保这些限定字段名称不会与其他字段名称发生冲突。
因此，可以将独立的视图组件任意组合，而且相互之间不会发生冲突。
在提交周期中，Web应用程序框架自动管理与这些限定字段名称相关的表单数据到组件的映射，因此开发人员不必考虑如何将组件组合在一起。
他们只需使用组件，Web应用程序框架会关心这些细节。
此外，在JSP页面的制作过程中，开发人员不使用这些限定名称。
相反，Web应用程序框架提供名为上下文标记的名称。
这些标记定义了嵌套容器和组件范围。
开发人员在这些范围内使用JSP中的本地名称，在运行时通过使用当前上下文，这些名称会自动而透明地转换成限定名称。
不但可以将视图组件任意组合，而且可以在父页面中将显示规范片段（JSP段和页面配件）任意组合。
Web应用程序框架开发人员则拥有了两种类型的视图组件供其重复使用，并可以将这些类型组合为多种形式。
这在其他框架中是完全不可能的。
24Web应用程序框架概述•2004年12月 高效的对象管理 许多框架过多地关注于应用程序中的对象复用，目的是为了效率更高并且具有可伸缩性，因为这样可以避免对象分配。
不幸的是，当前这种方法是错误的，一些著名的论坛上已经指出了此方法的错误。
然而在JDK1.0时间帧中，这可能不是正确的，特别是当与进程范围的同步点进行比较时，新型JVM中对象分配占用的资源相当少。
要获得最大的可伸缩性，框架必须尽可能避免并行线程之间的同步。
不遗余力共享对象的框架无疑会限制其可伸缩性。
而且，它们会显著地增加其复杂性，需要耗费大量的精力来避免与多线程相关的错误。
在许多情况下，这些框架也给那些时常没有准备好承担这种任务的应用程序开发人员施加了多线程编程方面的压力。
也许更多的担心是：直到建立在该框架基础上的应用程序用于生产中并承受很重的负载时，这些错误才会显露出来。
由于这些原因，Web应用程序框架采用了一种实用的方法。
它在其适当的位置复用对象，但允许根据需要分配其他对象。
Web应用程序框架的通用请求处理框架结构依靠由容器管理的共享对象实例，但是在标准请求处理过程中由开发人员使用的对象则缓慢地按需分配。
此方法不但为Web应用程序框架自身减少了复杂性，而且消除了所有类型的潜在错误，同时它还为应用程序代码完成了相同的操作。
开发人员不必担心损坏共享数据，调试也变得更加容易。
Web应用程序框架已证明此方法在生产部署时是最有效的，使用这种方法，每秒钟可以处理数百个请求，而且对象分配不会产生显著的延迟或对内存产生影响。
支持并行内容 目前大多数框架通过让开发人员访问Java资源束而提供了国际化支持。
JSP制作人员使用定制标记替换JSP中的静态内容，此定制标记在运行时从属性文件备份的资源束中获得本地化内容。
尽管这是一种有用的方法，但单独使用时它具有明显的缺陷，其中一个缺陷就是：JSP页面制作人员不能使用HTML编辑器以一种自然的方式制作页面，而必须编辑属性文件中的内容。
而且，此方法很大程度上假定围绕本地化内容的标记不发生更改，而实际上此标记可能会受到选定的设备或语言的很大影响。
因此，使用一个称作并行内容的替换方法，可以最有效地处理几种国际化支持。
Web应用程序框架为并行内容提供了完全支持，并行内容是JSP并行集的使用，将该集合中的每一个JSP定制成一个特定的语言、目标设备、输出标记（例如，XML、HTML或WML）或这些内容的任何组合。
每一个JSP引用相同的视图组件，因此仅包含内容和标记的变化。
然后，应用程序可以根据用户首选项或任何其他所需标准在运行时选择最适合的JSP以进行显示。
当尝试将内容本地化成西方和亚洲语言时（此时页面布局可能会受到很大影响），或者当尝试显示为类似于标准浏览器或启用蜂窝电话的不同设备类型时，并行内容运行良好。
其优点是：在页面不同的本地化版本之间业务逻辑和视图结构都保持一致性，同时允许（有时是明显的）显示差别。
第1章Web应用程序框架概述25 某些框架假定在JSP和应用程序组件之间存在一种静态关联，或使用组件和JSP关系的声明规范来尝试将页面流程自动化。
尽管在某些有限的情况下后一种方法具有自身的优点（然而存在更多显著的缺陷），但它没有考虑到使用并行内容时所需的灵活性。
强调JSP中程序构造的其他框架使用并行内容时会相当困难。
使用这些框架的开发人员必须复制和维护多个并行JSP之间的程序构造。
由于Web应用程序框架提供了显示事件以便将程序构造保持在JSP之外，因此在Web应用程序框架应用程序中，从来不必在并行JSP之间复制显示逻辑。
Web应用程序框架为并行内容提供了完全支持，应用程序可以在运行时按照任何开发人员定义的标准非常容易地选择所要显示的JSP。
并行JSP的查找也由开发人员定义，因此可以按照一种适合应用程序的方式组织并行内容。
与基于资源束的国际化策略一起，Web应用程序框架的并行内容功能提供了最灵活的国际化支持。
易于使用的高级功能 Web应用程序框架不但为应用程序和组件提供了低级框架结构，而且还提供了开发人员可以用来快速构建功能强大的应用程序的高级功能。
WebAction是其中的一种功能，允许开发人员使用最少的代码来完成通用的高级任务。
例如，开发人员可以在不同的请求之间调用下一个和前一个WebAction以自动翻阅DatasetModel中的数据行。
WebAction框架结构在不同的请求之间自动管理数据集位置，无需开发人员输入其他代码。
任何实现DatasetModel接口的模型都可以与这些WebAction一起使用。
Web应用程序框架提供的另一个高级功能是一组基于SQL的模型实现，这些模型实现可以自动管理面向模型的对JDBC资源的访问。
这些实现使用SQL查询和存储的过程来检索和保持RDBMS中的数据，无需开发人员关心JDBC使用细节或JDBC驱动程序使用中的不一致性。
当然，如果开发人员愿意，他们可以直接使用Web应用程序框架应用程序中的JDBC，但是Web应用程序框架核心中这些增值实现的出现，会让开发人员可以非常快速地构建企业功能应用程序。
其他框架则不能提供此级别的功能。
尽管开发人员可以将对象关系映射工具与任何框架（包括Web应用程序框架）一起使用，但他们至少需要做出一个明确的决定以使用应用程序体系结构中的复杂业务对象。
比较而言，Web应用程序框架基于SQL的模型让开发人员可以从应用程序领域中抽象出这些细节并将这些细节放到标准模型接口之后。
应用程序的其余部分不直接依赖于JDBC或SQL，因此更具有可维护性和一致性。
最后，Web应用程序框架提供了显著简化分层数据显示开发的TreeView和TreeModel原始框架。
由一组外观未知的定制标记对这些原始框架进行补充，这些标记允许开发人员为给定的树节点构造一个JSP文档并放入将进行选择性显示的部分。
由于这些标记本身不输出标记，因此可以在JSP片段和页面配件中使用这些标记来提供可插接的并且可定制的组件外观。
其他同时期的框架，都不能提供与这些组件相匹敌的组件。
26Web应用程序框架概述•2004年12月 工具准备 与其他框架不同，Web应用程序框架是从头开始设计的，直至最终使用GUI应用程序生成器来创建Web应用程序。
几乎所有其他同时期的框架都缺乏能够让功能强大的应用程序生成器可以集成的功能。
由于它们没有定义正式的字段、组件或模型，也没有提供以页面为中心的开发方法，因此在GUI生成器中进行操作的机会有限。
相反，可以将这样的集成限制为从模板单向生成代码，没有别的办法只能进行简单的手动代码编辑。
尽管工具准备已成为其基本设计的一部分，但由于若干原因，Web应用程序框架尚未提供这种功能。
在进行GUI应用程序开发之前，对于基于API的操作来说，框架必须是正确的、强健可靠的并且可以经得起检验。
开发人员必须能够做所需的任何事情（包括通过完善的API使用非常高级的技术）。
从一开始就注重工具支持的框架，通常仅侧重于该类型的操作，而无法提供精心设计的、易于使用的并且灵活的支持该框架结构的API。
这意味着开发人员不能进入面向工具的分层，进行类似于构建可复用的组件或以高级方式操作应用程序对象的操作。
而且，注重工具支持往往会将设计引向一个可能导致性能下降的方向。
也许产生性能问题的最常见的实现方法是使用共享对象。
在面向应用程序生成器的设计中，共享运行对象很常见，但是由于共享运行对象在运行时需要有效的同步，最终限制了可伸缩性。
项目不应该为了开发可伸缩性而放弃生产可伸缩性，相反，二者都应该可以实现。
Web应用程序框架认为：如果首先围绕接口和对象协议来设计框架，那么可在以后的阶段轻松添加GUI生成器支持（事实上，今天人们正在Web应用程序框架中从事这项工作）。
结果是：框架不但通过使用应用程序生成器提高了开发效率，而且还支持真正使框架适合企业的高级应用。
这也意味着在进程的初期，以工具为中心的设计并没有防碍可伸缩性和性能，即使应用程序生成器的支持可能会降低某些性能，开发人员也可以在开发可伸缩性和生产可伸缩性之间做出选择。
最后，侧重于应用程序生成器的框架通常需要附加的、有时是非标准的技术，这意味着它们需要其范围以外的附加库，这些附加库无法保证版本是正确的或者在给定的平台上是可用的。
必须由项目组手动将这些其他技术设置为可用，有时会因为版本冲突而难以设置。
Web应用程序框架认为这种做法比需要那些可能会与项目的部署体系结构发生冲突的附加库要好。
企业级性能 由于已经对Web应用程序框架进行了优化，消除了所有同步点，因此建立在Web应用程序框架基础上的应用程序与其运行的J2EE容器一样可以伸缩。
对于每个应用程序请求，Web应用程序框架所需的系统开销很小，且数量固定，而其他框架则要执行占用很多资源的同步，结果导致系统开销在短期内显著增长，或者是随负载的增加而增加，成为一个长期的问题。
第1章Web应用程序框架概述27 小结 Web应用程序框架提供的功能在同时期的Web应用程序框架中独树一帜。
目前大多数框架侧重于数据的显示，采用了各种各样的技术，例如JSP和XML。
只有非常少的框架真正去尝试满足开发人员的各种需求。
至于力图满足企业应用程序开发中各个范围内的要求，则只有Web应用程序框架。
Web应用程序框架经过不断的设计，始终定位在满足企业开发的要求，并将企业开发所面临的各种挑战减小到最低程度。
因此，Web应用程序框架通过以下几个方面满足了企业框架的标准：■Web应用程序框架鼓励用户使用已得到证实的最新设计模式，并为用户的使用提供 强有力的支持，从而实现了应用程序的一致性。
因此，开发人员可以在不同的项目组、不同的项目和不同的公司之间轻松施展才能。
Web应用程序框架不但提供了一个明显的、已获证明的开发应用程序的方法，而且让高级开发人员可以与基础的J2EE和Web应用程序框架平台进行低层的交互。
■Web应用程序框架提供了从低到高的全部功能，从现成的模型实现到基本的可扩展工具，使项目组在面对能够满足其需求的各种功能时，做出明智的取舍，达到完美的平衡。
■Web应用程序框架为增强应用程序的可维护性提供了具体方法，包括最新的、能够消除冗长数据转移的请求分发机制；通过良好定义的对象协议而增强的设计模式一致性；高级的组件开发工具、精心设计的应用程序事件和覆盖点；以及以页面为中心的开发模型。
■对于没有经验的开发人员，Web应用程序框架使用早已广为人知的应用程序开发概念，为他们提供一个清楚易懂、已获证明的应用程序开发方法，引导他们创建出设计一流的、高性能Web应用程序。
■对于高级开发人员，Web应用程序框架提供了有益的补充，在他们与基础的J2EE平台之间架起桥梁，提供了一个完善的机制以获得可扩展性。
■对于企业设计师，Web应用程序框架以其企业级的设计模式、有目共睹的高性能，以及用于抽象和封装对企业层资源的访问的正式机制，吸引了他们的目光。
Web应用程序框架成熟、强健可靠、稳定，有着极好的运行表现。
最重要的是，Web应用程序框架已经过实践的检验。
它已成功应用在生产企业应用程序中，每天为数百万用户服务，创造着数百万美元的收益，并已得到越来越多的企业开发人员、设计师和项目经理的认同。
基于上述及其他原因，以及Web应用程序框架已在企业中成功应用的事实，那些准备采用Web应用程序框架的企业完全可以相信，该框架符合企业级Web应用程序框架的所有标准。
28Web应用程序框架概述•2004年12月 第2章 Web应用程序框架设计和体系结构的常见问题 本章为初次使用Web应用程序框架的人员提供了有关Web应用程序框架设计及体系结构的常见问题解答。
本文档中包括的问题如下：■Web应用程序框架的适用对象？■拥有J2EE后，为什么还要使用Web应用程序框架？■难道Web应用程序框架不仅仅是另一个专用Web应用程序框架(JAPWAF)吗？■Web应用程序框架与其他J2EE框架有什么不同？■Web应用程序框架具有显示字段概念。
这不同于我所见过的J2EEBlueprints或其他 J2EE体系结构-为什么不直接从HelperBean中取值？■Web应用程序框架应用程序需要使用EJB吗？■Web应用程序框架应用程序是如何构造的？■如何实现请求流程和URL格式？■如何将视图Bean与会话或实体Bean关联起来？■将JSP范围设置为请求来简化线程安全编码并在每次请求时强制构造并破坏Bean， 这会有负面的性能影响吗？ Web应用程序框架的适用对象？ Web应用程序框架旨在满足J2EE开发人员的需要：要构建以增强中型、大型和超大型企业实力为目的的Web应用程序。
Web应用程序框架将强健可靠的设计模式与这些模式强健可靠的实现相结合，提供了一个企业Web应用程序的基础。
由于Web应用程序框架为可重用的类似于JavaBean的组件提供了核心设备，它也适用于那些想要提供可轻松集成到Web应用程序中的现成组件的第三方开发人员。
这些相同的功能使Web应用程序框架非常适于用作平台，构建垂直划分的Web应用程序或服务。
这是因为它的水平划分的扩展功能为最终用户和原始开发人员都提供了一个完善的方式，可以扩展或利用现有的垂直划分的功能。
29 拥有J2EE后，为什么还要使用Web应用程序框架？ J2EE是一个新兴的技术，尽管这项技术的出现非常令人振奋，但它还不能提供某些非J2EEWeb技术不断开发出来的丰富而快速的开发模型。
这不一定是件坏事情-不使用非标准应用程序API可以带来很多好处，而且J2EE提供的自由可以让许多Web开发任务变得更加轻松、快捷，结果也更容易维护。
但是，由于不断发展的行业需要尽快构建具有强大功能的Web应用程序，并且J2EE又将这类任务指定为最小级别，因此对于现实世界中几乎所有的Web开发项目来说，特别是企业Web应用程序，除了J2EE以外，仍然需要其他应用程序设计模式和附加功能。
这就是Web应用程序框架得以发展的原因：容易理解并接近本质，另外还提供了无与伦比的设计灵活性和一致性。
最重要的是，它完全基于纯粹的、符合标准的J2EE平台，因此您不必放弃J2EE才能使用Web应用程序框架。
相反，您可以从这两者中获益。
难道Web应用程序框架不仅仅是另一个专用Web应用程序框架(JAPWAF)吗？ 答案是否定的。
使用专用Web应用程序框架，您不仅要使用没有源代码的框架API，还要使用供应商提供的基本应用服务器平台。
如果您想要其中的一个而不需要另一个，那么很不幸，您需要将应用程序从一个供应商的解决方案转移到另一个供应商的解决方案，这意味着您需要从头开始编写应用程序。
Web应用程序框架则不同。
■Web应用程序框架完全基于J2EE平台。
在核心Web应用程序框架类中没有针对容 器的代码，这就意味着您可以在所喜欢的J2EE容器中使用Web应用程序框架而不需要进行更改。
Web应用程序框架已经在许多容器（例如ApacheTomcat、CauchoResin、AllaireJRun、SunJavaSystemApplicationServer、WebServer和IBMWebSphere）中进行了测试，它在所有容器中的用法都相同（除非容器存在错误，才需要稍微不同的用法）。
该框架已确定包含J2EE，并充分利用上述事实，且将您作为受益人。
■您拥有完整的Web应用程序框架源代码。
这意味着您可以调查、更改、修复、调节或配置框架中包括基础设计模式在内的每个细小的方面（尽管我们都希望将来可以不需要这样做），使其准确地满足您的需要。
我们建议您观察Web应用程序框架的工作原理，这不只是因为它将有助于更加快捷轻松地修复错误，而且还因为只有详细的技术性审查和讨论才能使Web应用程序框架从中获益。
■Web应用程序框架基本上是一个完全基于接口和对象协议的设计模式。
系统会提供这些接口的缺省实现，但是如果您不喜欢该实现的工作方式，可以覆盖不喜欢的部分。
或者，您自己重新实现接口来创建一个新类型的Web应用程序框架对象，此对象可以无缝地集成到框架的其余部分。
由于遵守相同的协议，新的Web应用程序框架对象可以与其他类型的Web应用程序框架对象进行交互式操作。
请在您首选的专用Web应用程序框架中尝试这项功能。
30Web应用程序框架概述•2004年12月 Web应用程序框架与其他J2EE框架有什么不同？ 如果仔细研究J2EE框架，就会发现：在创建Web应用程序框架前后，其他J2EE框架通常不能满足企业J2EE开发人员的各种需求。
相反，这些框架仅尝试满足有限的企业开发需求，因此，当用来构建现实世界中较大的企业Web应用程序时，这些框架就显示出不足。
也许最常见的故障主要集中在JSP显示和标记库上。
ApacheStruts可能是此类框架中最有名的示例。
尽管JSP是所有J2EEWeb应用程序的固有部分，且标记库对于减少JSP制作成本至关重要，但是它们不能成为试图最小化开发人员的工作量，同时又最大化应用程序可维护性（两者对于现实世界中的企业开发都至关重要）的框架的主要焦点。
例如，JSP中任何类型的程序构造都存在维护问题，这是因为程序构造会将应用程序功能暴露给JSP制作人员，还因为并行内容必须在许多潜在位置复制此功能。
另外，这些结构很少能够像Java代码那样丰富或功能强大，这样会导致一个更严重的问题，即需要在JSP中创建小脚本以处理复杂但相对常见的问题。
ApacheStruts专注于这种应用程序的开发，它的许多功能将实现此类功能作为目标。
对于不需要显著维护或扩展生命周期的中小型应用程序来说，尽管这些类型的功能可能带来较高的生产率，但是很显然这样的应用程序在企业中并不是典型的。
比较而言，Web应用程序框架认识到了JSP的优点并加以充分利用，而没有降低可维护性或应用程序开发人员较好控制JSP显示的能力。
它通过将视图层分为显示规范(JSP)和显示逻辑组件（视图组件）完成这些目标。
因为这些实体的组合会将程序构造同时保持在JSP之外，其中构造将与内容混合在一起，因此很难维护，尽管可以通过使用设计仔细的与视图相关的事件对显示提供更多控制。
其他框架的另一个常见故障是缺少连接至后端组件的模型或视图层接口的正式概念。
对于要快速构建可扩展Web应用程序的开发人员来说，在表示应用程序数据的视图组件和生成该数据的组件之间必须有一个明确的协议。
一般来说，在其他框架中没有这样一个协议或接口的规范，以致开发人员不得不以视图层的特定格式（例如一个具体的对象实例）提供数据，或者编写冗长的代码来处理从后端到视图的数据。
如果给定的是一个小项目，或者一个将来不需要对其后端层进行更改的项目，这将是可接受的。
而Web应用程序框架通过其模型接口在视图和后端之间提供了一个正式协议，使视图组件可以完全独立于后端组件。
此功能也使开发人员可以无缝地更改与视图关联的后端而不用更改视图本身。
这意味着在应用程序生命周期的早期，视图可以直接通过SQL查询显示，但是随着应用程序企业层的完善，就通过EJB显示数据，在所有这些操作中视图组件并不知道这种差别。
由于此原因，Web应用程序框架提供了一个完整的模型视图-控制器体系结构，而大多数其他框架实际上仅提供了一个视图-控制器体系结构。
最后，其他框架通常不考虑Web应用程序的提交周期，因此也不指定应用程序组件之间的互连和关系，难以维护。
这种忽略给开发人员带来了负担，不幸的是，当项目开始时，这种负担可能不会轻易显露出来。
例如，尽管许多框架为外出数据提供了结构，但很少或不会为外来数据提供结构，以致调用的组件被迫在“黑暗”中工作，不能确切知道在给定的请求调用上所接收到的数据内容。
第2章Web应用程序框架设计和体系结构的常见问题31 另外，指向相同组件的多个应用程序路径强制将目标组件所需的数据准备传输给调用者。
由于对象之间的依赖关系激增，这将大大妨碍可维护性。
通常，这种关系的激增反映为低级控制器逻辑的激增，用户需要手动将输入数据转移到目标组件或后端。
这可能导致显示页面时使用后端组件或模型，但处理来自先前显示页面的请求时并不直接使用它们的一种不对称性。
这种不对称给开发人员微管理后端组件造成了更大负担，并且会忙于处理Web应用程序容器中运行的低级细节。
相反，Web应用程序框架将此类功能合并到它的核心设计模式和实现中。
这可以将开发人员完全从显示视图和后备模型的数据传入和传出中解脱出来。
结果是，从开发人员的角度来看，模型在请求之间保持有状态但不会将实际状态负担强加给不会变化的应用程序。
简而言之，Web应用程序框架满足了企业开发人员的各种需求，从而避免了仅关注某一项技术或某一部分需求。
其他框架往往会采取可能满足企业开发的一个或两个方面的有限方法，但是很少能满足构建现实世界大规模的企业Web应用程序所需的所有关键方面。
Web应用程序框架具有显示字段概念。
这不同于我所见过的J2EEBlueprints或其他J2EE体系结构为什么不直接从HelperBean中取值？ 显示字段范例为更多原始技术提供了独特的方便。
在解释这些方便之前，请注意不要按照想象在应用程序中使用显示字段。
容器和子视图机制完全是基于可嵌入任意视图对象的概念。
子视图对象可能与整个的购物车显示或应用程序菜单一样设计得粗糙，也可能与独立显示字段一样设计得仔细。
该灵活性允许应用程序根据模块化部件进行组合，其中包括更加传统的面向显示字段的方法。
简而言之，您可以直接从Web应用程序框架的HelperBean中取出值，但是您可以确信一定有更好的方式。
每一个顶层ViewBean实例（或根视图）是ContainerView的一个实例，可以包含任意子视图集，某些子视图可以是显示字段视图。
TiledView也是子视图，除本身包含子视图之外，也可以任意嵌套。
视图的这种分层结构在某种程度上要比一般Web层开发人员所期望的复杂。
例如，许多此类开发人员可能只创建一个HelperBean，此HelperBean声明了所有必要的方法以获得所需的值，对相应的JSP进行显示。
这些值的源可能被封装在HelperBean的方法内。
他们可能使用标记中的"*"表示法，此标记会将提交的请求参数自动映射到Bean字段。
此操作很简单，但对于开发和维护却存在某些明显的不足。
尽管Web应用程序框架很相似，但子视图的使用对于维护精确的模型视图分离很重要。
例如，所有显示字段视图都绑定到一个模型。
这些视图不具有值的概念。
而且，所有显示字段现在均绑定在一起，尽管并不是所有显示字段均为数据绑定。
在某些情况下，此模型是DefaultModel的一个实例，只是内存中存储。
在其他情况下，绑定模型可能是SQL查询、存储过程、EJB、业务对象、XMLDOM或SOAP过程。
显示字段视图将与数据和业务行为的存储和管理完全分离。
32Web应用程序框架概述•2004年12月 显示字段也不知道所绑定的模型，因为显示字段可以绑定至任何模型，并且进行操作时无需知道该绑定模型的类型。
这意味着您不需要编写应用程序代码，就可以将值从值源转移到值的使用者（这一过程称为数据转移）。
相反，在Web应用程序框架中可以轻松地进行此操作，不同于在单纯的HelperBean环境中，在这种环境中您还需要在每一个Bean的取值函数中编写并维护针对目标的代码，才可以从EJB、JDBC、ResultSet等中获取值。
简而言之，显示字段提供了允许任意模型进行无缝插接的最小间接需求。
而且，由于显示字段与其关联模型通过通用模型接口发生交互式操作，后端数据可以用其本地格式表示，而无需占用很多资源处理仅视图层所需的数据格式。
另外，显示字段将显著改进通过典型的HelperBean/标记库方法创建的编程模型。
显示字段不但允许通过控制逻辑进行直观操作，而且还提供了针对类型的操作和HTML显示接口，这两种功能不可能通过其他方法实现。
例如，典型标记库方法的缺陷之一是HelperBean没有HTML显示进程的实际输入。
如果需要控制此显示，此故障通常会导致JSP中与应用程序相关的大量逻辑和属性成为小脚本。
例如，您可能需要跳过某个字段的显示，因为当前用户未经授权不能查看该显示。
在典型的JSP中，开发人员必须提供小脚本包围该显示，小脚本会将Java代码放入JSP中。
另一个方法是：增强标记处理程序以便按照某些标准机制调整其显示，这类似于检查条件变量。
使用这两种方法产生的问题是：与应用程序相关的数据和与显示相关的数据之间没有一致性或分区。
换而言之，它缺乏简洁性并难以维护。
Web应用程序框架通过提供两个方法中最佳的方法来处理此限制问题。
例如，要调整字段显示或自定义字段的HTML输出的开发人员最终可以在父视图中实现显示事件处理程序，而该处理程序在HTML显示过程中会被自动调用。
然后，开发人员可以跳过该字段的显示，或者直接操作HTML输出（例如，将文本框改成纯文本）。
或者，开发人员可以调用表示必要操作的显示字段视图上的方法，当字段由HTML显示子系统（JSP/标记库组合）显示时，将自动考虑到此操作。
因此，开发人员不需要将与显示相关的代码连同页面内容一起放入JSP、控制业务逻辑或面向业务的模型中，而可以增加显示字段显示进程或者轻松指向它。
这不仅可以将Java代码保持在JSP之外，而且要远比小脚本或其他控制HTML显示的方法功能更强大。
另一个益处是它能够更加一致。
显示字段还允许开发人员可以将HTML页面用作服务器端的状态对象。
当用户单击HTML页面上的按钮或HREF时，请求最终会路由回显示该按钮或HREF的视图，并且会调用对应于该对象的事件处理程序。
但是，在调用事件处理器之前，Web应用程序框架会使用提交的请求参数重写所有的显示字段和视图。
结果是，从开发人员的角度来看，页面保持有状态并且只响应来自用户的命令。
在很大程度上，开发人员处理事件的方式与在胖客户端应用程序中处理事件的方式相同，方法是实现事件处理程序并且基于请求及其更新字段值采取操作。
由于显示字段一直绑定到模型中，因此对字段中的值所进行的任何更改都将自动反映到模型中。
这使开发人员可以在类似于传统胖客户端和类似于正式MVC编程式样之间选择最有效的折衷方案。
注意到使用HelperBean和使用显示字段两种方法中的任何一个都可以实现虚包设计模式非常重要，因为进出HTML页面的接口是由这些对象处理的。
由此接口提供的数据值可能来自许多源（包括多个后备EJB、业务对象、结果集等等），在抽象术语中，这 第2章Web应用程序框架设计和体系结构的常见问题33 些都可以作为模型。
但是，鉴于传统HelperBean通过自定义代码管理这些模型，很少或不具有一致性或可复用性，Web应用程序框架将这些模型抽象为模型的正式定义，并且在模型和绑定到模型的视图之间指定了一个清楚的协议。
这个正式协议具有以下优点：■它允许显示字段在由视图表示的虚包和作为此虚包后备的模型集之间提供灵活的映 射。
由于Web应用程序框架中包含了基于XML的声明功能（已经在进行中），显示字段将允许对此虚包进行声明更改，这将大大简化应用程序开发并显著减少开发时间。
■由于此虚包可以轻松地进行更改，使用声明支持而无需重新编译就可以相当轻松地将对后备模型的更改反映到应用程序的视图部分。
此方式与传统HelperBean方法比较起来，在传统方式中开发人员可能需要向其HelperBean添加存取函数和赋值函数，或者修改所需的代码以便从后备模型中获取值或向后备模型发送值。
由于这些经过仔细设计的更改及其所需的重新编译，将显著增加开发时间，降低工作效率和对象的重复使用。
Web应用程序框架应用程序需要使用EJB吗？ 答案是否定的。
与任何其他J2EE应用程序一样，您可以获得EJB的引用并在Web应用程序框架应用程序中直接使用此引用。
但是，尽管EJB是J2EE的一类组件，但并不是必需组件。
而且，对于应用程序体系结构来说，EJB是相对复杂的附件，当前还有某些明显的缺陷。
由于基于EJB的体系结构提出了许多独特的挑战，并要求在应用程序设计和实现的许多领域进行大量的附加投资，因此多数Web开发人员不准备使用此结构。
因此，要求使用EJB可能会带来问题。
但是，使用EJB是会得到支持和帮助的。
Web应用程序框架提供了基于灵活的和可插接式模型-视图体系结构的有价值的功能，此体系结构与面向Web和面向EJB的应用程序都兼容。
作为直接使用EJB的一种替换方法，开发人员可以使用由EJB备份的或直接实现的模型。
EJB的集成与Web应用程序框架中任何其他类型的模型一样都是无缝的，并提供自动数据绑定和其他高级功能。
Web应用程序框架中包含了一个名为BeanAdapterModel的类作为开始使用EJB的方法，该类将标准的模型接口映射到任意JavaBean属性上。
如果拥有用户EJB，您可以将其打包装入此适配器模型，使显示字段可以直接访问其属性/值，而无需任何附加代码。
使用此适配器，从显示上的用户Bean对值进行显示并自动将值推回提交上的Bean中。
您也可以使用该类将访问打包装入本地业务对象-适配器不会关心其封装的对象是远程的还是本地的。
Web应用程序框架应用程序是如何构造的？ Web应用程序框架应用程序是由一个或多个模块组成的完全独立的实体。
每个模块是整个应用程序的一个功能片或逻辑组。
一个应用程序中至少需要一个模块，但是其他模块是可选的并可随时添加。
34Web应用程序框架概述•2004年12月 每一个Web应用程序框架应用程序都定义了称为应用程序Servlet的类，这是一个基类，可以由此基类派生出所有针对模块的Servlet。
应用程序的客户端仅访问模块Servlet。
应用程序Servlet仅作为通用基类为模块Servlet提供服务，并为在单个类中合并通用应用程序级别的事件处理器提供机会。
模块Servlet会考虑到这些事件仅用于模块的特殊性。
这些Servlet一起形成了每一个Web应用程序框架应用程序的请求处理框架结构。
每一个模块都对应了应用程序的一个子软件包，除了包含针对该模块的一个最小化Servlet框架结构之外，还包含一个或多个逻辑页面。
每一个模块可能还包含支持模块和其他非Web应用程序框架类（当然，模块中的类通常也可以使用此模块之外的类）。
模块中的每一个逻辑页面都至少包含一个JSP和一个ViewBean。
ViewBean是相应JSP的HelperBean，它和Web应用程序框架标记库一起提供了显示/应用程序事件框架结构。
每一个ViewBean都包含可重复使用子视图对象的任意分层结构，将这些对象汇编到可以在几分钟内创建完全合格的和数据绑定的页面。
如何实现请求流程和URL格式？ 所有请求最初都由控制器Servlet处理（每一个模块拥有一个Servlet，每个应用程序拥有几个Servlet），由开发人员选择此Servlet的URL。
此Servlet将请求分发到针对请求的控制器对象(ViewBean)，然后此对象会将请求转发到另一个资源（JSP、ViewBean或其他Web资源）。
Servlet的源代码及其分发机制完全在开发人员的控制之下，所以鼓励开发人员通过阅读精心注释的源代码学习此机制的详细资料。
如何将视图Bean与会话或实体Bean关联起来？ 它们之间没有直接的关系。
视图Bean是一个JSP工作或HelperBean(usebean)。
每一个视图Bean都充当其对等JSP的中心支持。
如果需要，会话和实体Bean可以通过视图Bean或其关联的模型或视图访问。
将JSP范围设置为请求来简化线程安全编码并在每次请求时强制构造并破坏Bean，这会有负面的性能影响吗？ 一般而言，支持持久性应用程序对象的系统开销明显高于使用当前方法的系统开销。
测试表明，与专用的非J2EE容器先前所需要的系统开销以及典型的Web应用程序所需的系统开销比较起来，当前方法产生的系统开销很小。
实际上，新型JVM中的对象分配占用资源很少，这就证明了此方法的价值。
但是，这并不意味着已忽略了这种方法的系统开销。
第2章Web应用程序框架设计和体系结构的常见问题35 尽管某些非J2EE容器为了提高效率提供了持久性应用程序对象，但是这些对象对于客户端来说并不是有状态的。
因此，每一个客户端的状态信息必须在每个请求上重新生成。
等效的应用程序对象已经经过了仔细设计，并尽可能减少系统开销。
在大多数情况下，这就相当于在任何情况下都必须重新创建每一个请求的有用的状态信息。
另外，Web应用程序框架支持对这些对象的优化访问，因此仅在需要时才创建这些对象。
所以说在大多数情况下，基于Web应用程序框架的应用程序在处理和内存消耗方面总体上要比非J2EE应用程序明显有效。
设计一个有效使用持久性应用程序对象的框架结构是不可能的。
SunJavaSystemApplicationServer和其他高度可伸缩的Servlet容器都使用多个JVM，用户的请求不必路由回相同的地址空间。
这意味着在任何情况下必须重新初始化每一个请求的持久性应用程序对象。
此操作的系统开销至少不会少于再次简单创建对象的系统开销。
另外，将应用程序对象放到会话中并不十分可行，由于它占用很多资源并且至少需要解序列化，解序列化比简单的对象分配更昂贵。
将功能层添加到Web应用程序框架中以支持持久性应用程序对象，会将开发人员从基本容器中完全分离出来。
此操作通常违反了尽可能接近标准J2EE的设计原则。
尽管已产生了这些缺陷，但是在将来如果益处大于缺陷，仍然可以提供使用持久性应用程序对象的功能。
然而，目前这种功能仅适用于小范围内的应用程序，而对于典型的Web应用程序框架应用程序是没有帮助的。
36Web应用程序框架概述•2004年12月 索引
A API（J2EE以前）,11
B BluePrints样例,J2EE,17本书的组织结构,6标记库,19表示层模式,至少实现J2EE,17并行内容,支持,25
D 调试（J2EE以前）,12顶层软件包,18对称显示,21
F 分层视图和组件范围,24分层虚包,19服务到工作者委托,12
G GUI开发,胖客户端和瘦客户端,12概述,技术,18概述,应用程序框架,11至28高效的对象管理,25工具准备,27功能,高级和低级,13功能,开发高级的,15 功能,类型,17功能,易于使用,高级,26
J J2EE应用程序框架,出现,12JSP范围设置为请求,35JSP页,基于HTML的,19
K 开发人员没有经验的,14有经验的,14 开发人员,第三方,15开发人员,新J2EE,15可维护性,14框架,企业,13
M 模型-视图-控制器(MVC)模式,17
P 胖客户端GUI开发,12
Q 企业级性能,27前言,5至9请求流程和URL格式,如何实现,35 37
S Servlet体系结构,类型I和类型II,12 设计模式分发程序视图,16复合实体,16复合视图,16服务到工作者,16服务定位器,16服务激励器,16会话虚包,16快速道读取器,16拦截过滤器,16命令,17模型-视图-控制器,17前台控制器,16适配器,17视图帮助器,16使用,16数据访问对象,16业务委托,16值列表处理器,16传送对象,16传送对象汇编程序,16 设计师,企业,14视图Bean和会话或实体Bean关联,35瘦客户端GUI开发,12
U UI,基于MVC的,12
W Web应用程序构建的挑战,11 Web应用程序,大规模企业,12Web应用程序框架 不做什么,15发展,14功能,15工作原理,16基于J2EE标准,20仅仅是另一个专用Web应用程序框架(JAPWAF) 吗？,30 面向J2EE开发人员,15设计和体系结构的常见问题,29适用对象,15,29为什么不从HelperBean中取值？,32为什么不使用J2EE,30应用程序是如何构造的？,34应用程序需要使用EJB吗？,34与其他J2EE框架有什么不同,31与其他Web应用程序框架的区别,20
X 线程安全编码,35性能,13
Y 一致性,应用程序,13应用程序,Web,J2EE以后,12应用程序,Web,J2EE以前,11应用程序开发模型,中小型,13应用程序框架 企业的标准,13应用程序事件,23应用程序一致性,20
Z 正式的模型实体,22子软件包,19组件,构建可重复使用的,15 38Web应用程序框架概述•2004年12月
U.S.A.保留所有权利。
该发行版本中可能包含由第三方开发的内容。
Sun、SunMicrosystems、Sun徽标和Java是SunMicrosystems,Inc.在美国和其他国家/地区的商标或注册商标。
所有SPARC商标的使用均已获得许可，它们是SPARCInternational,Inc.在美国和其他国家/地区的商标或注册商标。
标有SPARC商标的产品均基于由SunMicrosystems,Inc.开发的体系结构。
UNIX是X/OpenCompany,Ltd.在美国和其他国家/地区独家许可的注册商标。
本服务手册所介绍的产品以及所包含的信息受美国出口控制法制约，并应遵守其他国家/地区的进出口法律。
严禁将本产品直接或间接地用于核设施、导弹、生化武器或海上核设施，也不能直接或间接地出口给核设施、导弹、生化武器或海上核设施的最终用户。
严禁出口或转口到美国禁运的国家/地区以及美国禁止出口清单中所包含的实体，包括但不限于被禁止的个人以及特别指定的国家/地区。
本文档按“原样”提供，对所有明示或默示的条件、陈述和担保，包括对适销性、适用性和非侵权性的默示保证，均不承担任何责任，除非此免责声明的适用范围在法律上无效。
目录 前言5
1.Web应用程序框架概述11简介：构建Web应用程序的挑战11构建Web应用程序：J2EE以前11构建Web应用程序：J2EE以后12J2EE应用程序框架的出现12企业应用程序框架的标准13Web应用程序框架的概念14概述14Web应用程序框架的适用对象15Web应用程序框架的功能15Web应用程序框架定义的补充15Web应用程序框架的工作原理16设计模式的使用16功能的类型17Web应用程序框架与其他Web应用程序框架的区别20基于J2EE标准20一个常见的范例20应用程序一致性20
3 对称显示/提交处理21正式的模型实体22应用程序事件23分层视图和组件范围24高效的对象管理25支持并行内容25易于使用的高级功能26工具准备27企业级性能27小结28
2.Web应用程序框架设计和体系结构的常见问题29Web应用程序框架的适用对象？29拥有J2EE后，为什么还要使用Web应用程序框架？30难道Web应用程序框架不仅仅是另一个专用Web应用程序框架(JAPWAF)吗？30Web应用程序框架与其他J2EE框架有什么不同？31Web应用程序框架具有显示字段概念。
这不同于我所见过的J2EEBlueprints或其他J2EE体系结构-为什么不直接从HelperBean中取值？32Web应用程序框架应用程序需要使用EJB吗？34Web应用程序框架应用程序是如何构造的？34如何实现请求流程和URL格式？35如何将视图Bean与会话或实体Bean关联起来？35将JSP范围设置为请求来简化线程安全编码并在每次请求时强制构造并破坏Bean，这会有负面的性能影响吗？35 索引37 4Web应用程序框架概述•2004年12月 前言 《Web应用程序框架概述》概要介绍了Web应用程序框架并针对其概念、工作原理以及如何与其他的Web应用程序框架进行区分等内容展开讨论。
阅读本书须知 在阅读本书之前，您应该熟悉利用现有J2EEWeb技术，例如servlet和JavaServletPages™（JSP™pages）生成Web应用程序时所用到的概念。
下列资源可提供更多信息：■《Java2PlatformEnterpriseEdition规范》 #platformspec■《J2EE教程》 /j2ee/tutorial■《JavaServlet规范2.3版》 #specs■《JavaServerPages规范1.2版》 #specs 注--Sun对本文档中提到的第三方Web站点的可用性不承担任何责任。
对于此类站点或资源中的（或通过它们获得的）任何内容、广告、产品或其他材料，Sun并不表示认可、也不承担任何责任。
对于因使用或依靠此类站点或资源中的（或通过它们获得的）任何内容、产品或服务而造成的或连带产生的实际或名义损坏或损失，Sun概不负责，也不承担任何责任。
5 本书的组织结构 第1章，第11页上的“Web应用程序框架概述”，概要介绍Web应用程序框架。
第2章，第29页上的“Web应用程序框架设计和体系结构的常见问题”，为初次使用Web应用程序框架的人员提供了有关Web应用程序框架设计及体系结构的常见问题解答。
排版惯例 字体 AaBbCc123 AaBbCc123AaBbCc123 AaBbCc123 含义 命令、文件和目录的名称；计算机屏幕输出 键入的内容，以便与计算机屏幕输出相区别书名、新词或术语以及要强调的词 命令行变量；用实际的名称或值替换 示例 编辑.cvspass文件。
使用DIR列出所有文件。
Searchplete. >loginPassword: 请阅读《用户指南》中的第6章。
这些称为类选项。
必须保存您的更改。
要删除文件，请键入DELfilename。
相关文档 JavaStudioEnterprise文档包括AcrobatReader(PDF)格式的书籍和教程、发行说明、联机帮助以及HTML格式的教程。
访问联机文档 访问SMWeb站点，或者通过SunJavaStudioEnterprise开发人员资源门户(/jsenterprise/)的文档链接，可以查看该部分所描述的文档。
6Web应用程序框架概述•2004年12月 您可以通过上的Web站点()，阅读、打印和购买SunMicrosystems手册。
■《SunJavaStudioEnterprise7发行说明》-文件号码819-1303-10 介绍最新的发行更改和技术说明。
■《SunJavaStudioEnterprise7安装指南》（PDF格式）-文件号码：819-1301-10 介绍如何在每台支持的平台上安装SunJavaStudioEnterprise7集成开发环境(IDE)，包括其他相关信息，例如系统需求、升级指导、服务器信息、命令行开关、已安装的子目录、数据库集成以及有关如何使用“更新中心”的信息。
■《构建J2EE应用程序》-文件号码819-1299-10描述如何将EJB模块和Web模块组装到J2EE应用程序中，以及如何部署和运行J2EE应用程序。
■Web应用程序框架文档（PDF格式）■《Web应用程序框架组件编写人员指南》-文件号码819-1285-10 介绍Web应用程序框架组件体系结构以及设计、创建和分发新组件的过程。
■《Web应用程序框架组件参考指南》-文件号码819-1287-10 介绍Web应用程序框架库中可用的组件。
■《Web应用程序框架概述》-文件号码819-1289-10 介绍Web应用程序框架及其概念、工作原理以及与其他应用程序框架的区别。
■《Web应用程序框架教程》-文件号码819-1291-10 介绍使用Web应用程序框架工具生成Web应用程序的机制和技术。
■《Web应用程序框架开发人员指南》-文件号码819-1293-10 提供创建和使用应用程序组件的步骤（这些应用程序组件经组装后通过Web应用程序框架可用来开发应用程序），并解释如何在大多数J2EE容器中部署该应用程序。
■《Web应用程序框架IDE指南》-文件号码819-1295-10介绍SunJavaStudioEnterprise72004Q4IDE的各个部分，着重介绍用于开发Web应用程序框架应用程序的可视工具的使用。
■《Web应用程序框架标记库参考》-文件号码819-1297-10概要介绍Web应用程序框架标记库，并对该库中可用的标记进行综合引用。
教程 SunJavaStudioEnterprise7教程可以帮助您了解IDE的功能。
每个教程都提供技术和代码样例，您可以在开发大量的应用程序时使用或进行修改。
所有的教程都采用SunJavaSystemApplicationServer来解释部署。
前言
7 所有教程都可以通过开发人员资源门户中的“教程和代码库”链接进行访问。
在IDE中选择“帮助”>“示例和教程”可以访问到所有这些教程。
■快速入门指南概要介绍了SunJavaStudioIDE。
如果您初次使用SunJavaStudioIDE或者希望获取某个特定功能的快速介绍，请首先访问快速入门教程。
这些教程描述了如何开发简单的Web应用程序和J2EE应用程序、生成Web服务；如何开始进行UML建模和重构。
您只需花几分钟的时间便可以了解快速入门教程。
■教程着眼于SunJavaStudioIDE的单一功能。
如果您希望了解某项特定功能的详细信息，请尝试使用教程。
取决于示例的着眼点，有些教程从头开始生成应用程序，有些教程则是在提供的源文件上构建应用程序。
您可以花一个小时或更少的时间完成该教程。
■解说式教程利用视频来说明某项功能或技术。
请尝试使用解说式教程，获取关于IDE的可视化概述或某项特定功能的进一步说明。
您只需花几分钟的时间便可以完成解说式教程。
此外，您还可以随意启动和停止解说式教程。
联机帮助 您可以在SunJavaStudioEnterprise7IDE中获得联机帮助。
通过按下帮助键（MicrosoftWindows环境中为F1，Solaris环境中为Help键），或者选择“帮助”→“内容”可以打开帮助。
执行以上任意操作都将显示一个帮助主题列表和一个搜索工具。
使用易读格式的文档 该文档以易读格式提供，以方便残障用户使用辅助技术进行阅读。
您还可以按照下表所描述的信息找到文档的易读版本。
文档类型 书籍和教程教程 发行说明 易读版本的格式和位置 HTML格式，位置： HTML格式，位置：开发人员资源门户(/jsenterprise)的“示例和代码库”链接 HTML格式，位置： 8Web应用程序框架概述•2004年12月 Sun欢迎您提出意见和建议 Sun致力于提高文档质量，并欢迎您提出宝贵的意见和建议。
请通过电子邮件将您的意见发送至以下地址：docfeedback@请在电子邮件的主题栏中注明书名（《Web应用程序框架概述》）及其文件号码(8191289-10)。
前言
9 10Web应用程序框架概述•2004年12月 第1章 Web应用程序框架概述 本章概要介绍了Web应用程序框架，包括以下章节：■简介：构建Web应用程序的挑战■Web应用程序框架的概念■Web应用程序框架的工作原理■Web应用程序框架与其他Web应用程序框架的区别■小结 简介：构建Web应用程序的挑战 构建Web应用程序：J2EE以前 由于J2EE™解决了第一代Web开发人员面临的核心问题，因此，J2EE，尤其是其Web层组件（Servlet和JSP）已经非常成功。
在J2EE出现以前，这些开发人员在构建简单的应用程序时都必须对付大量不同的编程模型、API和各种不同的服务器。
由于选择能满足应用程序要求的技术，就必须得考虑各种庞杂的因素，因此要构建企业规模的应用程序就变得更加困难。
实际构建一个应用程序是另一个棘手的问题，而平台不成熟、API不匹配、跨平台集成问题和缺乏高度可伸缩的开发和维护模型使这个问题变得更加复杂。
尽管服务器供应商通过提供功能强大的高级应用程序框架解决了大量编程和开发可伸缩性问题，但是在这些框架中，只有少数几个框架基本假定可以通用，而通用协议或框架结构并不能真正通用。
这些框架通常连接至服务器供应商的专用服务器框架结构，尽管它们有可能构建功能强大的、强健可靠的企业应用程序，但无法更改供应商或者简便地利用由其他供应商提供的技术。
如果不重写应用程序，则实质上无法实现从一个供应商的平台转移至另一个供应商的平台。
11 企业设计师采用了几种策略以避免这种供应商封锁，最普遍的策略就是在体系结构中增加大量抽象内容。
尽管此策略解决了某些问题-可以使企业业务对象和进程从Web容器细节中分离-但是又产生了其他问题。
这些抽象内容大大增加了应用程序的复杂性，不可避免地给开发和部署带来了困难。
设计师越是试图远离专用API时，调试此复杂框架结构就越困难。
由于每一个新项目都会带来新的体系结构和约束，可能与开发人员先前遇到的体系结构和约束不兼容，因此Web开发人员的技能变得越来越不能重复使用。
每一个应用程序都自成一体，缺乏必要的一致性，当基础应用程序框架没有为开发人员和设计师提供有力的指导时，这种情况尤其严重。
尽管某些约束有助于专注应用程序开发工作，但某些框架如此高级，以致开发人员必须融合各种功能以完成高级的（在某些情况下是例行的）任务。
构建Web应用程序：J2EE以后 J2EE的出现解决了第一代Web应用程序开发所特有的许多问题。
开发人员第一次可以依赖容器及其应用程序组件之间的标准协议，并保证所有J2EE兼容的容器都提供相同的精心设计的API。
设计师和开发人员可以从纷繁复杂的专用框架、API和容器中解脱出来。
但是，自由是有代价的。
尽管J2EE是应用程序框架的坚实基础，但是它本身并不稳固。
J2EE规范未采用应用程序开发领域的建议做法。
J2EE将设计（或采用）一个满足应用程序开发需要的应用程序框架结构的主要任务留给了设计师和开发人员。
J2EE不能独自完成此项任务。
J2EE应用程序框架的出现 要开发现实世界的应用程序，特别是大规模的企业Web应用程序，开发人员必然会发现他们必须创建某种框架。
J2EE提供了针对Web的基本平台，但是实际应用程序开发所需的其他内容必须由其他软件提供，而在内部开发一个框架可能既费时又容易产生错误。
因此，已出现大量建立在J2EE之上的可重复使用的（可重复使用性并不高）Web应用程序框架，每一个框架都试图满足某一范围内的开发人员的需求。
例如，某些框架专门处理输出到客户端的数据的显示，而其他框架则处理输入数据的验证。
还有一些框架试图将胖客户端和瘦客户端的GUI开发统一起来。
由于J2EE废除了在第一代Web应用程序开发过程中使用的实际体系结构，每一个J2EE项目现在必须评估和选择一个适合自身要求的最佳应用程序体系结构。
通用概念和术语已逐步形成，以帮助讨论这些体系结构（其中的示例包括类型I和类型IIServlet体系结构、服务到工作者委托以及基于MVC的UI）。
尽管这些概念都很基本、很重要，可以广泛应用于从非常小到非常大的各种应用程序。
但是，这些概念都没有真正提供如何以一种可重复、可维护和可伸缩的方式构建Web应用程序的细节。
12Web应用程序框架概述•2004年12月 为了强调最后这一点，几乎所有同时期的应用程序框架都要求使用类型II、服务到工作者和基于MVC的体系结构，然而，这些框架在实现、可扩展性以及其对开发人员设置的约束方面存在明显差别。
知道基本的体系结构仅有助于开发人员了解该框架。
它在帮助开发人员学习该框架，或甚至将其与其他框架进行比较时（特别是当这些框架针对不同的应用程序规模时）所起的作用都非常小。
并非只要具有足够的术语，就能有效地描述现代框架的功能。
因此，需要更加详细的分析以真正理解一个框架向另一个框架提供的内容，特别是框架向企业应用程序开发提供的内容。
仅按照功能检查表工作是明显不够的。
企业应用程序框架的标准 依靠经过测试和已获证明的体系结构，构建Web应用程序的过程中要比在其他应用程序开发领域中重要得多。
例如，在响应不是最适合的体系结构或技术选择时，胖客户端应用程序的承受能力相对较强。
当完全拥有自己的新型工作站时，即便最抽象的客户端应用程序体系结构也都将能满足性能上的要求。
当必须通过松耦合的网络在共享硬件（此硬件同时支持几百或几千个用户）上运行相同的应用程序时，这种情况根本不会出现。
在这种领域中，错误选择体系结构或技术，所导致的差别往往是：要么以及时的方式响应请求、要么根本不响应请求；或者要么能较好调节开发和生产、要么仅完成其中一项任务而不能完成两项任务。
在中小型应用程序开发领域中，某些因素导致的故障是可以原谅的，因为这里少量开发人员完全致力于一个应用程序。
在这种情况下，由于将来更改的范围以及与其他项目组接触的范围有限，因此体系结构可能会更加容易修改；并且当出现问题时，项目组成员可以轻松地协调解决。
可以轻松地共享编码标准和最佳方法，更新应用程序的陈旧部分仅需要几个小时的工作。
项目组往往具有相似的专业水平，可以保持稳定、长期合作。
由于这些应用程序的用户群体较小或容许较慢的响应时间，因此性能通常不是关键因素。
企业应用程序的开发与中小型应用程序的开发模型相比，结果正好相反。
项目组之间的通信很难；更改应用程序会产生较大的影响；最佳方法很少能够传播到子项目组之外；更新应用程序的某些部分简直是不可能；开发人员的流动性大；开发人员的专业变化范围很广。
最后，性能是绝对关键的，因为性能可能在用户决定是继续使用还是摒弃该应用程序时起着决定性的作用。
相对于易用性而言，用户可能更希望应用程序具有更及时的响应。
因此，辅助企业Web应用程序开发的任意框架必须在其设计和实现中解决这些约束。
更重要的是，它必须使这些约束对应用程序开发工作的影响降低到最小程度，甚至在理想条件下消除影响。
因此，任何企业框架都必须完成以下工作：■提供应用程序一致性，从而可以在不同的项目组、项目以及公司之间复用开发人员 的技能。
开发应用程序应该很容易入门，但是不应该限制开发人员的能力。
■提供高级和低级功能，使项目组可以找到满足其需求的真正平衡并在限制时间内完 成项目。
第1章Web应用程序框架概述13 ■提供可用来提高应用程序可维护性的具体方法（以可以想到的各种不同方式），使设计师和开发人员不必自己完成这项工作。
■对那些没有经验的开发人员进行指导，因为并非所有的开发人员天生就具有相同的能力，某些开发人员可能在基于Web的应用程序领域中缺乏经验，甚至缺乏企业开发领域的经验。
■为高级开发人员提供辅助工具，以便他们直接使用基础的J2EE平台创建高级功能，而无需在框架功能上浪费时间。
■向企业设计师求助，让需要合并的高级体系结构要素可以立即用于框架或与框架兼容。
企业设计师应该适应框架谨慎选择体系结构的方式，最好他或她会对资源做出同样的选择。
最重要的是，在企业设置中，框架必须是经过证明的、成熟的、强健可靠的并且性能良好。
框架的用户必须知道期望得到的结果，在开始任何开发工作之前，他们必须确保框架能够满足这些要求。
本章的其余部分介绍了要成为真正的企业类Web应用程序框架的Web应用程序框架应该如何处理这些问题以及如何满足这些条件。
Web应用程序框架的概念 概述 Web应用程序框架是基于标准的成熟且功能强大的J2EEWeb应用程序框架，它适用于企业Web应用程序的开发。
Web应用程序框架融合了一些常见概念，例如显示字段、应用程序事件、组件分层结构和以页面为中心的开发方法，并使用基于“模型-视图-控制器”模式和“服务到工作者”模式的最新设计。
Web应用程序框架建立在行业中领先的软件工程师、顾问、Web应用程序开发人员和企业Web设计师的集体经验的基础之上。
从2000年1月起，Web应用程序框架已处于开发中，到2000年6月开始投入使用。
从那一时刻起，Web应用程序框架已用于许多现实世界的企业Web应用程序中，并成功地用于支持数百万用户以及每天数百万美元金融交易量的站点。
14Web应用程序框架概述•2004年12月 Web应用程序框架的适用对象 Web应用程序框架主要用于满足要构建中型、大型和超大型Web应用程序的J2EE开发人员的需要。
尽管Web应用程序框架可以并且已经用于小型Web应用程序，但其主要的优点在这种规模下并不十分明显。
当应用程序经过长期维护、经历了许多更改并在其范围内不断发展时，Web应用程序框架会变得格外出色。
简而言之，Web应用程序框架在帮助开发企业应用程序方面表现突出。
由于Web应用程序框架为可重复使用的组件提供了核心设备，因此它非常适合于要提供可轻易集成到Web应用程序中的现成组件的第三方开发人员。
特别值得一提的是，由于这些扩展功能为最终用户和最初的开发人员都提供了一个定义良好的方法，用以扩展和利用现有的垂直划分功能，所以这些相同的功能使得Web应用程序框架非常适于作为构建垂直划分Web服务的平台。
Web应用程序框架的功能 Web应用程序框架使用含有最新技术的J2EE设计模式，帮助开发人员构建企业Web应用程序。
它提供了一个基于设计模式的、企业设计师可以将其体系结构的其他部分附着在上面的框架。
Web应用程序开发人员会发现这是一种简单的开发方法；企业设计师会发现这是一种描述清晰的设计模式，该设计模式以明确定义的方法与其他企业层和企业组件进行集成。
Web应用程序框架为开发人员提供低级和高级框架结构、设计模式以及完整的组件模型，帮助他们构建可重复使用的组件。
开发人员定义的组件是与Web应用程序框架进行交互操作的最好对象，就好像这些组件是本地组件一样。
可以在应用程序中、跨应用程序以及跨项目和公司任意组合和重复使用组件。
最后，Web应用程序框架还可以引导新的J2EE开发人员熟悉Web应用程序开发，并通过向高级J2EE开发人员提供一个强大的工具箱，让他们能够开发出通过其他框架无法开发的高级功能。
Web应用程序框架定义的补充 Web应用程序框架不是一个企业层框架，这意味着它不会直接帮助开发人员创建EJB、Web服务或其他类型的企业资源。
尽管Web应用程序框架适用于企业应用程序开发，但它实际上是这些企业层资源的客户端，因此提供了访问这些资源的正式且最佳的机制。
第1章Web应用程序框架概述15 Web应用程序框架的工作原理 设计模式的使用 Web应用程序框架是建立于行业可以接受的、最新设计模式和技术的基础之上，作为一个J2EE表示层框架，它实现了JavaSoft发布的J2EE核心模式并严格依赖于它。
下表列出了Web应用程序框架所使用的已发布的J2EE设计模式。
拦截过滤器 拦截过滤器 前台控制器复合视图 视图帮助器分发程序视图服务到工作者业务委托会话虚包 服务定位器值列表处理器 复合实体传送对象汇编程序传送对象服务激励器数据访问 对象 表示法 表示法 表示法表示法表示法表示法 表示法 表示和业务业务业务业务 业务业务 业务集成集成 J2EE核心模式（请参阅/blueprints/corej2eepatterns/index.html）
X JavaBluePrints模式目录（请参阅/blueprints/patterns/catalog.html）*
X X
X X
X X
X X
X X
X X
X X
X X
X X
X X
X X
X X
X Web应用程序框架执行 Servlet2.3过滤器XXXX
X X****** **** ****
X 16Web应用程序框架概述•2004年12月 拦截过滤器 快速道读取器模型-视图控制器 适配器 命令 表示法 表示法全部(A)表示法 J2EE核心模式（请参阅/blueprints/corej2eepatterns/index.html） JavaBluePrints模式目录（请参阅/blueprints/patterns/catalog.html）*
X Web应用程序框架执行
X X
X XX *注意：J2EEBluePrints样例应用程序（例如PetStore）实现了许多业务层和集成层模式，但是仅作为这些模式的演示才有效。
而且，许多这些模式都被指定使用J2EEBluePrints应用程序所采用的EJB。
但是，Web应用程序框架对其一无所知。
由于各种原因，Web应用程序框架在某些特定的情况下提供了EJB使用的替换方法，这些替换方法从Web层实体使用业务层和集成层的某些模式。
**Web应用程序框架至少实现了J2EE表示层模式，但是，像只有表示层框架所期待的那样，Web应用程序框架不需要实现业务层和集成层模式。
这些模式的大多数可以作为向企业层和集成层开发人员推荐使用的最佳方法，这些模式是完全兼容的并且可以与该框架的表示层模式相集成。
除了使用上面列出的模式之外，Web应用程序框架还建立在多层JSP/Servlet体系结构的基础之上，并完全围绕反映这些模式的接口和对象协议进行设计：首先它是一组集成的协同设计模式，然后它是这些模式的一个实现。
在Web应用程序框架的模式中，最主要的是模型-视图-控制器(MVC)模式。
尽管其他框架也声称是MVC框架，但实际上它们通常着重于该模式组件的一个（也许是两个）组件，但很少着重于所有三个组件。
此外，其他框架通常声称JSP（也许使用一个定制标记库）包含一个完整而正确的视图层。
它们还多次声称针对应用程序的业务对象包含一个完整而正确的模型层。
这些说法并不真实。
Web应用程序框架完整地提供了MVC模式的三个组件。
它使用具体的关系定义正式的视图和模型实体，并提供一个允许应用程序以适当的方式确定控制器逻辑范围的高级逻辑控制器。
Web应用程序框架的视图层整合了JSP技术，但是又与JSP技术不同。
同样，Web应用程序框架的模型层也整合了其他J2EE技术，但是与任何J2EE技术都不同。
由于以上原因以及下面要介绍的其他原因，Web应用程序框架为开发人员提供了其他框架完全不能比拟的可扩展性。
第1章Web应用程序框架概述17 功能的类型 Web应用程序框架功能在逻辑上分为三部分。
■Web应用程序框架核心■Web应用程序框架组件■Web应用程序框架扩展 Web应用程序框架核心 通常将Web应用程序框架核心简称为Web应用程序框架。
它定义了基本的接口、对象协议和原语，还为应用了Web应用程序框架的应用程序提供了所需的最小框架结构。
Web应用程序框架核心不提供组件库，但是可以为组件编写人员提供使能技术。
Web应用程序框架核心包含基于视图的原始框架（例如ContainerView、TiledView和TreeView）以及基于模型的原始框架（例如DatasetModel、QueryModel和TreeModel）。
Web应用程序框架核心也为请求分发和可重复使用的命令对象提供原始框架。
通过使用这些原始框架，开发人员可以轻松地创建针对应用程序的组件或者可以在项目内或不同的项目之间共享的可重复使用的组件。
Web应用程序框架核心也包含使开发人员可以立刻开始构建高性能应用程序的高级功能。
以下各节中包含了这些功能的详细信息。
Web应用程序框架组件 Web应用程序框架组件利用Web应用程序框架核心的框架结构，为应用程序开发提供了高级的、可重复使用的组件。
这些组件风格各异，适用于不同的使用范围。
例如，水平划分的Web应用程序框架组件往往成为最普遍的可用组件，其优点在于灵活并且可以定制。
这些类型的组件可以由许多不同的Web应用程序框架用户群体在不同的项目和公司之间使用，通常不局限于任何特定的外观和功能。
垂直划分的Web应用程序框架组件是为特定使用情况量身定做的，可以提供高级功能和易用性。
这些类型的组件适用范围较窄，但是由于其范围定义明确，这些组件可以最小程度地保持参数化并使用特定的外观和功能。
所有Web应用程序框架组件可以使用由Web应用程序框架核心提供的所有设备，并建立在高级功能（例如WebAction、基于SQL的模型实现和TreeView）的基础上。
Web应用程序框架扩展 最后，Web应用程序框架扩展以一种Web应用程序框架兼容的方式提供对非J2EE设备的访问。
在许多情况下，Web应用程序框架扩展允许在Web应用程序框架应用程序中无缝地使用针对容器的功能。
扩展与Web应用程序框架组件的区别在于扩展着重于技术集成而不是应用程序开发。
18Web应用程序框架概述•2004年12月 技术概述 Web应用程序框架，或更确切地说Web应用程序框架核心是纯粹的Java，并打包为一个行业标准的JAR文件。
Web应用程序框架定义了若干个顶层软件包，如下所示：.jato-请求处理框架结构mand-与命令相关的接口和实现.jato.taglib-定制JSP标记库.jato.model-与常规模型相关的接口和实现.jato.view-与常规视图相关的接口和实现 每一个软件包都包含更加针对派生的子软件包（例如针对HTML的视图实现和针对SQL的模型实现）。
Web应用程序框架组件或Web应用程序框架扩展没有正式的软件包或类，它们是纯粹的逻辑分类。
编写Web应用程序框架应用程序时，开发人员从现有的Web应用程序框架类中派生出针对应用程序的子类，或以一个针对应用程序的方式实现某些Web应用程序框架接口。
在大多数情况下，开发人员将使用现有的Web应用程序框架核心实现作为超类，因此继承了大量有用的操作。
（组件开发人员更有可能直接实现一组Web应用程序框架接口。
） 应用程序对象是围绕某页面的中心概念而组织的。
每一个页面都包含一个显示规范-通常是一个JSP包含静态内容和标记（另外还包括定制Web应用程序框架标记）-一个类包含该页面的根视图分层结构。
每一个对服务器的请求都返回一个页面作为结果。
应用程序的页面流量由开发人员编写的控制逻辑来确定。
除了由开发人员提供的关系之外，在一个页面和另一个页面之间没有固定的关系。
在HTML中，每一个显示页面通常都包含一个或多个用户可以激活的链接或按钮。
每激活一个链接或按钮都会将数据发回服务器，并导致调用针对该激活的命令对象。
此命令对象可以自己采取行动，或将请求的处理委托给开发人员定义的事件方法。
最终，请求将被转发到一个负责对客户端的响应进行显示的资源。
在大多数情况下，此资源是一个基于HTML的、使用Web应用程序框架标记库对动态内容进行显示的JSP页面。
标记库使用Web应用程序框架视图组件来获得其显示的数据。
这些视图对象与一个或多个模型对象相关联，并按照需要从模型对象中提取数据。
因此，Web应用程序框架视图可以充当许多模型的分层虚包。
这些视图可以在多个不同的页面之间通过不同的模型重复使用。
由于模型没有显示相关性或视图相关性，因此通常可以由多个视图使用。
以页面形式接收响应之后，用户可以激活链接或按钮，并向Web应用程序框架应用程序发回一个请求。
该请求将发回到显示页面的相同对象。
此操作允许Web应用程序框架的框架结构将提交的数据映射回其源自的相同视图（和此类模型），并提供该数据虚拟持久性。
开发人员与应用程序对象和提交的数据进行交互式操作，好像中间从来没有一个响应请求循环。
将数据映射回原始对象之后，针对该链接或按钮的命令对象将被激活，循环将再次开始。
第1章Web应用程序框架概述19 Web应用程序框架与其他Web应用程序框架的区别 以下各节概要介绍Web应用程序框架和其他同时期的Web应用程序框架的主要差别。
基于J2EE标准 许多框架将Servlet当作一项切实可行的技术而不使用JSP，反之亦然。
还有某些框架宣称它们采用了这些标准，但是实际上，它们仅仅是可以通过使用基本Servlet级别的集成在J2EE容器中运行的专用容器。
Web应用程序框架直接包含了类似于Servlet和JSP的J2EE标准，同时，开发人员仍然可以自由地使用J2EE提供的功能。
Web应用程序框架不是一个容器内的容器，也不是一个将开发人员从J2EE中抽象出来的分层。
相反，它增强了促进企业Web应用程序开发的J2EE功能，同时开发人员仍然可以按照自己的意愿与J2EE/Web应用程序框架进行交互式操作。
一个常见的范例 Web应用程序框架提供了显示字段、应用程序事件、组件分层结构和以页面为中心的开发方法，所有这些结构都经过了时间的考验并且非常适合于开发人员通过使用Swing、Delphi、VisualBasic或PowerBuilder技术来熟悉客户端应用程序开发。
尽管由于提供的是Web范例而存在差别，但这些常见的结构可以将一种对Web应用程序框架的自然感知传递给开发人员，可以明显加快应用程序的开发。
这也意味着Web应用程序框架特别适合与应用程序生成器（例如ForteforJava或JBuilder）进行集成（要获得有关应用程序生成器集成的更多信息，请参阅工具准备小节）。
应用程序一致性 许多现代Web应用程序框架相当灵活，在某些情况下，这是设计的基本目的。
它们有意识地在应用程序的某些方面（例如其模型层）力求非规范。
相反，它们着重于应用程序设计的一个或两个部分，最常见的是MVC体系结构的控制器和视图部分，而将其余部分留给开发人员。
某些设计师和开发人员可能从来不认为灵活性是一个缺陷，但是当考虑企业开发时，灵活性就可能是一个缺陷。
尽管将灵活性当成一个缺陷开始听起来可能感觉奇怪，但灵活性和应用程序一致性之间存在着对立关系。
具有最大灵活性的框架（例如J2EEAPI自身）可以导致应用程序的开发方式各种各样。
20Web应用程序框架概述•2004年12月 不加限制的灵活性或不确定的开发方向，会让没有经验的设计师和开发人员使用一些似乎可以完成手头任务的技术（或任何技术），即使此技术最终存在缺陷。
当框架不能提供一个在整个开发任务中可以遵循的清晰路径时，开发人员很可能会使用破坏或偏移框架提供的优点的技术。
此外，每一个独立的项目组可能都会使用不同的技术，以致即使在相同的应用程序中，一个组也不能轻易地理解或维护另一个组的工作。
最糟的情况是：在应用程序的某一部分中使用的一项有缺陷的技术会损害应用程序的其余部分，以致应用程序的性能或可伸缩性受到影响。
当一个没有经验的设计师或开发人员为应用程序选择了一个较差的全局方向时，这种情况很有可能出现。
这样一个选择可能导致整个应用程序出现难以处理的体系结构问题，最坏的情况是应用程序最终无法工作。
不幸的是，对于Web应用程序开发人员来说，大多数框架的灵活性在开发和生产中容易产生相反的结果。
如上所述，一个好的企业框架应该以正确的方向引导没有经验的开发人员，而不是以引导高级开发人员的方式来引导他们。
许多框架只实现了后者，这是因为它们在体系结构或应用程序开发的某些方面是不规范的，或者是因为设计原理或设计缺陷，造成这些框架只能做成这样。
项目开始时，开发人员要做出许多选择，包括许多由于没有正确选择而给整个项目带来明显危害的选择。
比较而言，Web应用程序框架为Web应用程序体系结构和应用程序开发提供了一个固有的已经证明的方向，而且不会妨碍其他方法的使用。
通过提供与应用程序进行交互式操作的明确定义的点以及扩展、加强或覆盖现有操作的清晰方式，Web应用程序框架做到了这一点。
使用Web应用程序框架开发Web应用程序和使用其他框架来开发Web应用程序所存在的区别是：刚使用Web应用程序框架的用户不需要做出选择（可能是不好的）便可以开始使用。
该用户从一开始就可以使用一种常规方法，当可以更熟练地使用Web应用程序框架和J2EE之后，其他方法和技术将变得易于理解了。
而且，开发人员此时完成的所有工作仍然可以与后来所使用的更高级的技术保持一致。
其结果是，用Web应用程序框架编写的应用程序比使用其他框架编写的应用程序彼此之间更加相似。
它们在高级和低级功能的使用上都更加一致，因此更易于维护。
对称显示/提交处理 目前许多应用程序框架是从定制标记库发展而来，定制标记库是一种广泛使用的技术。
在某些情况下，这些框架和定制标记库类似，也许还包含一个或两个附加接口。
其结果是，这些框架缺乏长远考虑，严重局限于发送给用户的数据的显示，为处理来自用户的数据所提供的帮助较少。
这些框架也许较好地满足了开发人员某一部分的需求，但这是以牺牲其他部分为代价的。
在类型II体系结构中，提交（请求）周期过程中不包含类似于JSP的显示技术。
这意味着如果视图表示法仅在JSP中定义，则提交周期逻辑不能利用此视图表示法。
该逻辑反而只接收原始参数列表作为输入。
这样，开发人员就只能使用这些值的原始形式，得到的帮助很少或几乎没有。
他们突然进入到最基本的Servlet技术的深处。
通常，这些框架中没有指定应用程序对象之间的清晰关系，因此难以维护。
由于这些框架向输入数据提供较少的结构或根本不提供结构，因此调用的组件不得不在“黑暗”中工作，无法可靠地了解给定的请求调用上所收到的数据内容。
项目开始时，这将给项目带来负担（也许不会很快显露出来），随着应用程序逐渐变大，这些负担将很快成为一个主要因素。
第1章Web应用程序框架概述21 缺少对称显示和提交周期通常会导致对象之间的依赖关系激增。
通常，这种关系的激增反映为低级控制器逻辑的激增，用户需要手动将输入数据转移到目标对象或后端。
它可能会导致一种不对称性：显示页面时使用后端对象或模型，但处理来自先前显示页面的请求时又不直接使用后端对象或模型。
这种不对称性为开发人员微管理后端组件带来了许多负担，并且会造成开发人员忙于处理Web应用程序容器中运行着的低级细节。
在以显示为中心的体系结构中，不能获得较好的生产力和可维护性。
比较而言，Web应用程序框架以对称方式依靠其正式的视图层帮助显示和提交周期。
鉴于其他框架不能精确地将其视图层定义为JSP或某些其他种类的内容显示技术，Web应用程序框架将显示规范(JSP)与视图组件进行了区分。
只有将这些结合在一起才是完整的视图层。
一个Web应用程序框架应用程序主要定义视图组件的分层结构，然后从显示规范中引用这些组件。
在显示和提交周期中，开发人员以相同的方式与这些视图组件进行交互式操作。
视图组件是规范的视图表单。
正式的模型实体 如上一节所述，许多框架过多地关注于帮助向用户提供数据显示的技术。
这类框架最常见的种类是那些着重于XML和XPath的框架。
尽管这些框架可以吸引开发人员使用最新的一流技术，但是这些框架在应用程序提交周期中提供给开发人员的帮助很少，并经常需要以XML格式或某些其他面向显示的格式来表示应用程序数据。
将应用程序数据强制表示为以框架为中心，这项任务比较繁重，某些情况下，这可能是一个致命的缺陷。
相反，Web应用程序框架认为应用程序应该能够以一种视图未知的方式表示其数据，并为获得该数据提供一个正式的机制，无需暗含特别的数据格式。
因此，Web应用程序框架提供了一个正式的模型实体，该实体定义了几个所有模型必须实现的标准方法。
使用一个任意的针对模型的关键字，模型用户（包括Web应用程序框架视图）能够以一种标准方式获得模型数据，无需做出任何有关该模型如何在内部表示其数据的假设。
根据这个原因，Web应用程序框架组件可以按照相同的方式与任何模型进行交互式操作，允许将不同的模型插入到相同的视图。
模型可以互换，因此它们表示的数据也可以互换。
不必纯粹为了显示而将数据处理成特定的格式，视图层无需了解与其进行交互式操作的数据的具体类型。
不同类型的模型可以在一个应用程序中共存，不需要视图层识别其本地数据格式之间的任何差别。
对于模型用户来说，XML/XPath、JDBC、JDO和其他企业数据看起来都是相同的，因此Web应用程序框架可以包含着重于这些数据格式之一的任何框架的开发方法。
最后，在企业层资源上插入模型结构，进一步增加了抽象程度，不但使应用程序设计更加一致，而且显著减轻维护的负担。
在正式定义从企业层获得的数据时，开发人员还需要在应用程序的各个层之间定义一种正式但属于松耦合的协议。
有了这种协议，今后就可以用一种完善的方式轻松地修改应用程序。
出现不利情况的几率会降低，即便出现不利情况，也会很快被识别出来。
22Web应用程序框架概述•2004年12月 应用程序事件 Web应用程序框架向开发人员提供了大量与应用程序相关的事件。
有三种类型的事件：常规请求事件、特定请求事件和显示事件。
常规请求事件包含类似于onBeforeRequest()、onSessionTimeout()和onUncaughtException()的事件。
开发人员可以使用这些事件来响应常规的应用程序和请求生命周期情况（包括错误状态）。
缺省情况下，与错误相关的事件使用一个一致的本地化的机制向用户报告错误，开发人员可以覆盖这些事件以采取针对应用程序的操作。
特定请求事件基于用户的操作发生。
当用户激活页面上的链接或按钮（在Web应用程序框架中也称作CommandField），该请求将导致调用服务器上与该激活操作相对应的命令对象。
在响应这些操作时，尽管用户可以提供他们自己的命令对象，缺省的命令实现将请求的处理委托给表单的请求处理事件方法handle
该事件在CommandField的父容器上调用，因此该事件位于最初显示链接或按钮的组件范围之内。
在此事件处理器中，开发人员可以采取自己喜欢的任何操作，按自己的意愿处理请求，或者将请求的处理委托给另一个对象。
此Web应用程序框架功能与其他Web应用程序框架所提供的类似处理请求功能之间的主要区别在于：此事件在与之相关的组件上被调用，每个链接或按钮都经过仔细设计。
其他框架通常为每个HTML表单只提供一个设计粗糙的事件处理器，并让开发人员基于用户的操作来创建条件代码。
作为字段更改集，这既杂乱又难以维护。
由于每次在表单中添加或删除新的链接或按钮时，都必须更改单个事件处理器，而不管它是否包含在组件中，该方法也会造成使用模块化的、独立组件变得困难（要获得有关此缺陷的更多信息，请参阅分层视图和组件范围小节）。
最后，Web应用程序框架还提供了经过仔细设计的字段级别的显示事件。
显示事件在页面显示的过程中被调用，这让开发人员可以进入通过其他方式几乎不可能实现的显示进程。
从这些事件中，开发人员可以访问标记处理器，也可以访问JSP页面上下文和输出流。
显示事件可以同时用于跳过字段的显示或终止当前显示页面。
它们也可以用于调节由JSP显示的传出内容，并提供高级的内容过滤功能。
此外，显示事件会将与组件相关的显示逻辑封装到该组件内，因此，即使使用高级的显示技术，也可以为组件提供高度的可复用性。
最重要的是，显示事件在JSP之外保留了Java代码或类似于程序的结构。
JSP中任何种类的程序构造通常都存在着维护问题，这不仅是由于它将应用程序功能暴露给JSP制作人员，同时还由于并行内容必须在潜在的许多位置复制此功能（要获得有关并行内容的更多信息，请参阅支持并行内容小节）。
对于需要较少维护或不需要显著维护或生命周期有限的中小型应用程序来说，尽管这些种类的功能可能带来较高的生产率，但这样的应用程序在企业中不具有代表性。
许多框架都强调这种应用程序的开发，众多框架的功能都以使用模仿传统编程语言的各种程序构造来实现这些功能为目标。
比较而言，Web应用程序框架认识到了JSP的优点并加以充分利用，并没有降低可维护性或应用程序开发人员控制JSP显示的能力。
第1章Web应用程序框架概述23 分层视图和组件范围 大多数框架将平面名称空间用于HTML表单中的数据字段名称。
此平面名称空间严重限制了视图组件可以组合的方式。
例如，无法在同一个表单上使用两个名为名称字段的组件。
从全局的角度来看，在所有组件和表单中，唯一的方法是提供所有字段的唯一名称。
很明显，开发过程中此解决方法不会发生变化，并且减少了全局组件市场的开发。
对于依靠紧耦合的表单对象词汇索引的框架来说，情况更糟糕。
在这种情况下，一个HTML表单对应一个Java对象（通常是一个JavaBean），每个表单字段都对应取值方法和赋值方法。
类似于name的简单表单字段名称可以轻易地映射到类似于getName()和setName()的Java方法。
但是，如上所述，如果开发人员想要使用可复用的组件，那么他们几乎不能使用这些简单的名称，而需要使用所提供的全局唯一的名称。
将类似于ponentA.name的复杂字段名称映射到Java方法名称会非常不精确。
这样的名称必须符合Java方法命名标准，因此唯一可行的选项是getCom_ponentA_name()和setCom_ponentA_name()。
也许可以使用，但会不精确或者难以维护。
任何依靠单一对象作为表单字段名称的虚包的框架都会妨碍视图组件的使用-不管是否在多个页面上使用该表单的一部分，所有在该页面或表单上使用的数据都必须由单一的对象接口反映。
开发人员可以创建一个仅由表单使用的对象，然后委托给其他更容易复用的对象，但是这会需要冗长的并且难以维护的数据转移代码，而且这不是一个真正的组件体系结构。
此外，它还需要一个编译步骤以便在表单或页面中进行更改，这是要与应用程序生成器一起工作的框架所存在的一个严重缺陷。
比较而言，Web应用程序框架为没有基于紧耦合的表单对象词汇索引的HTML表单字段提供了一个分层名称空间。
每一个显示字段视图是作为父容器视图的子项而创建的，并在该容器内使用简单的本地名称。
因此，它无疑继承了一个限定的唯一全局名称。
即使本地名称与其他容器中的名称相同，也可以确保这些限定字段名称不会与其他字段名称发生冲突。
因此，可以将独立的视图组件任意组合，而且相互之间不会发生冲突。
在提交周期中，Web应用程序框架自动管理与这些限定字段名称相关的表单数据到组件的映射，因此开发人员不必考虑如何将组件组合在一起。
他们只需使用组件，Web应用程序框架会关心这些细节。
此外，在JSP页面的制作过程中，开发人员不使用这些限定名称。
相反，Web应用程序框架提供名为上下文标记的名称。
这些标记定义了嵌套容器和组件范围。
开发人员在这些范围内使用JSP中的本地名称，在运行时通过使用当前上下文，这些名称会自动而透明地转换成限定名称。
不但可以将视图组件任意组合，而且可以在父页面中将显示规范片段（JSP段和页面配件）任意组合。
Web应用程序框架开发人员则拥有了两种类型的视图组件供其重复使用，并可以将这些类型组合为多种形式。
这在其他框架中是完全不可能的。
24Web应用程序框架概述•2004年12月 高效的对象管理 许多框架过多地关注于应用程序中的对象复用，目的是为了效率更高并且具有可伸缩性，因为这样可以避免对象分配。
不幸的是，当前这种方法是错误的，一些著名的论坛上已经指出了此方法的错误。
然而在JDK1.0时间帧中，这可能不是正确的，特别是当与进程范围的同步点进行比较时，新型JVM中对象分配占用的资源相当少。
要获得最大的可伸缩性，框架必须尽可能避免并行线程之间的同步。
不遗余力共享对象的框架无疑会限制其可伸缩性。
而且，它们会显著地增加其复杂性，需要耗费大量的精力来避免与多线程相关的错误。
在许多情况下，这些框架也给那些时常没有准备好承担这种任务的应用程序开发人员施加了多线程编程方面的压力。
也许更多的担心是：直到建立在该框架基础上的应用程序用于生产中并承受很重的负载时，这些错误才会显露出来。
由于这些原因，Web应用程序框架采用了一种实用的方法。
它在其适当的位置复用对象，但允许根据需要分配其他对象。
Web应用程序框架的通用请求处理框架结构依靠由容器管理的共享对象实例，但是在标准请求处理过程中由开发人员使用的对象则缓慢地按需分配。
此方法不但为Web应用程序框架自身减少了复杂性，而且消除了所有类型的潜在错误，同时它还为应用程序代码完成了相同的操作。
开发人员不必担心损坏共享数据，调试也变得更加容易。
Web应用程序框架已证明此方法在生产部署时是最有效的，使用这种方法，每秒钟可以处理数百个请求，而且对象分配不会产生显著的延迟或对内存产生影响。
支持并行内容 目前大多数框架通过让开发人员访问Java资源束而提供了国际化支持。
JSP制作人员使用定制标记替换JSP中的静态内容，此定制标记在运行时从属性文件备份的资源束中获得本地化内容。
尽管这是一种有用的方法，但单独使用时它具有明显的缺陷，其中一个缺陷就是：JSP页面制作人员不能使用HTML编辑器以一种自然的方式制作页面，而必须编辑属性文件中的内容。
而且，此方法很大程度上假定围绕本地化内容的标记不发生更改，而实际上此标记可能会受到选定的设备或语言的很大影响。
因此，使用一个称作并行内容的替换方法，可以最有效地处理几种国际化支持。
Web应用程序框架为并行内容提供了完全支持，并行内容是JSP并行集的使用，将该集合中的每一个JSP定制成一个特定的语言、目标设备、输出标记（例如，XML、HTML或WML）或这些内容的任何组合。
每一个JSP引用相同的视图组件，因此仅包含内容和标记的变化。
然后，应用程序可以根据用户首选项或任何其他所需标准在运行时选择最适合的JSP以进行显示。
当尝试将内容本地化成西方和亚洲语言时（此时页面布局可能会受到很大影响），或者当尝试显示为类似于标准浏览器或启用蜂窝电话的不同设备类型时，并行内容运行良好。
其优点是：在页面不同的本地化版本之间业务逻辑和视图结构都保持一致性，同时允许（有时是明显的）显示差别。
第1章Web应用程序框架概述25 某些框架假定在JSP和应用程序组件之间存在一种静态关联，或使用组件和JSP关系的声明规范来尝试将页面流程自动化。
尽管在某些有限的情况下后一种方法具有自身的优点（然而存在更多显著的缺陷），但它没有考虑到使用并行内容时所需的灵活性。
强调JSP中程序构造的其他框架使用并行内容时会相当困难。
使用这些框架的开发人员必须复制和维护多个并行JSP之间的程序构造。
由于Web应用程序框架提供了显示事件以便将程序构造保持在JSP之外，因此在Web应用程序框架应用程序中，从来不必在并行JSP之间复制显示逻辑。
Web应用程序框架为并行内容提供了完全支持，应用程序可以在运行时按照任何开发人员定义的标准非常容易地选择所要显示的JSP。
并行JSP的查找也由开发人员定义，因此可以按照一种适合应用程序的方式组织并行内容。
与基于资源束的国际化策略一起，Web应用程序框架的并行内容功能提供了最灵活的国际化支持。
易于使用的高级功能 Web应用程序框架不但为应用程序和组件提供了低级框架结构，而且还提供了开发人员可以用来快速构建功能强大的应用程序的高级功能。
WebAction是其中的一种功能，允许开发人员使用最少的代码来完成通用的高级任务。
例如，开发人员可以在不同的请求之间调用下一个和前一个WebAction以自动翻阅DatasetModel中的数据行。
WebAction框架结构在不同的请求之间自动管理数据集位置，无需开发人员输入其他代码。
任何实现DatasetModel接口的模型都可以与这些WebAction一起使用。
Web应用程序框架提供的另一个高级功能是一组基于SQL的模型实现，这些模型实现可以自动管理面向模型的对JDBC资源的访问。
这些实现使用SQL查询和存储的过程来检索和保持RDBMS中的数据，无需开发人员关心JDBC使用细节或JDBC驱动程序使用中的不一致性。
当然，如果开发人员愿意，他们可以直接使用Web应用程序框架应用程序中的JDBC，但是Web应用程序框架核心中这些增值实现的出现，会让开发人员可以非常快速地构建企业功能应用程序。
其他框架则不能提供此级别的功能。
尽管开发人员可以将对象关系映射工具与任何框架（包括Web应用程序框架）一起使用，但他们至少需要做出一个明确的决定以使用应用程序体系结构中的复杂业务对象。
比较而言，Web应用程序框架基于SQL的模型让开发人员可以从应用程序领域中抽象出这些细节并将这些细节放到标准模型接口之后。
应用程序的其余部分不直接依赖于JDBC或SQL，因此更具有可维护性和一致性。
最后，Web应用程序框架提供了显著简化分层数据显示开发的TreeView和TreeModel原始框架。
由一组外观未知的定制标记对这些原始框架进行补充，这些标记允许开发人员为给定的树节点构造一个JSP文档并放入将进行选择性显示的部分。
由于这些标记本身不输出标记，因此可以在JSP片段和页面配件中使用这些标记来提供可插接的并且可定制的组件外观。
其他同时期的框架，都不能提供与这些组件相匹敌的组件。
26Web应用程序框架概述•2004年12月 工具准备 与其他框架不同，Web应用程序框架是从头开始设计的，直至最终使用GUI应用程序生成器来创建Web应用程序。
几乎所有其他同时期的框架都缺乏能够让功能强大的应用程序生成器可以集成的功能。
由于它们没有定义正式的字段、组件或模型，也没有提供以页面为中心的开发方法，因此在GUI生成器中进行操作的机会有限。
相反，可以将这样的集成限制为从模板单向生成代码，没有别的办法只能进行简单的手动代码编辑。
尽管工具准备已成为其基本设计的一部分，但由于若干原因，Web应用程序框架尚未提供这种功能。
在进行GUI应用程序开发之前，对于基于API的操作来说，框架必须是正确的、强健可靠的并且可以经得起检验。
开发人员必须能够做所需的任何事情（包括通过完善的API使用非常高级的技术）。
从一开始就注重工具支持的框架，通常仅侧重于该类型的操作，而无法提供精心设计的、易于使用的并且灵活的支持该框架结构的API。
这意味着开发人员不能进入面向工具的分层，进行类似于构建可复用的组件或以高级方式操作应用程序对象的操作。
而且，注重工具支持往往会将设计引向一个可能导致性能下降的方向。
也许产生性能问题的最常见的实现方法是使用共享对象。
在面向应用程序生成器的设计中，共享运行对象很常见，但是由于共享运行对象在运行时需要有效的同步，最终限制了可伸缩性。
项目不应该为了开发可伸缩性而放弃生产可伸缩性，相反，二者都应该可以实现。
Web应用程序框架认为：如果首先围绕接口和对象协议来设计框架，那么可在以后的阶段轻松添加GUI生成器支持（事实上，今天人们正在Web应用程序框架中从事这项工作）。
结果是：框架不但通过使用应用程序生成器提高了开发效率，而且还支持真正使框架适合企业的高级应用。
这也意味着在进程的初期，以工具为中心的设计并没有防碍可伸缩性和性能，即使应用程序生成器的支持可能会降低某些性能，开发人员也可以在开发可伸缩性和生产可伸缩性之间做出选择。
最后，侧重于应用程序生成器的框架通常需要附加的、有时是非标准的技术，这意味着它们需要其范围以外的附加库，这些附加库无法保证版本是正确的或者在给定的平台上是可用的。
必须由项目组手动将这些其他技术设置为可用，有时会因为版本冲突而难以设置。
Web应用程序框架认为这种做法比需要那些可能会与项目的部署体系结构发生冲突的附加库要好。
企业级性能 由于已经对Web应用程序框架进行了优化，消除了所有同步点，因此建立在Web应用程序框架基础上的应用程序与其运行的J2EE容器一样可以伸缩。
对于每个应用程序请求，Web应用程序框架所需的系统开销很小，且数量固定，而其他框架则要执行占用很多资源的同步，结果导致系统开销在短期内显著增长，或者是随负载的增加而增加，成为一个长期的问题。
第1章Web应用程序框架概述27 小结 Web应用程序框架提供的功能在同时期的Web应用程序框架中独树一帜。
目前大多数框架侧重于数据的显示，采用了各种各样的技术，例如JSP和XML。
只有非常少的框架真正去尝试满足开发人员的各种需求。
至于力图满足企业应用程序开发中各个范围内的要求，则只有Web应用程序框架。
Web应用程序框架经过不断的设计，始终定位在满足企业开发的要求，并将企业开发所面临的各种挑战减小到最低程度。
因此，Web应用程序框架通过以下几个方面满足了企业框架的标准：■Web应用程序框架鼓励用户使用已得到证实的最新设计模式，并为用户的使用提供 强有力的支持，从而实现了应用程序的一致性。
因此，开发人员可以在不同的项目组、不同的项目和不同的公司之间轻松施展才能。
Web应用程序框架不但提供了一个明显的、已获证明的开发应用程序的方法，而且让高级开发人员可以与基础的J2EE和Web应用程序框架平台进行低层的交互。
■Web应用程序框架提供了从低到高的全部功能，从现成的模型实现到基本的可扩展工具，使项目组在面对能够满足其需求的各种功能时，做出明智的取舍，达到完美的平衡。
■Web应用程序框架为增强应用程序的可维护性提供了具体方法，包括最新的、能够消除冗长数据转移的请求分发机制；通过良好定义的对象协议而增强的设计模式一致性；高级的组件开发工具、精心设计的应用程序事件和覆盖点；以及以页面为中心的开发模型。
■对于没有经验的开发人员，Web应用程序框架使用早已广为人知的应用程序开发概念，为他们提供一个清楚易懂、已获证明的应用程序开发方法，引导他们创建出设计一流的、高性能Web应用程序。
■对于高级开发人员，Web应用程序框架提供了有益的补充，在他们与基础的J2EE平台之间架起桥梁，提供了一个完善的机制以获得可扩展性。
■对于企业设计师，Web应用程序框架以其企业级的设计模式、有目共睹的高性能，以及用于抽象和封装对企业层资源的访问的正式机制，吸引了他们的目光。
Web应用程序框架成熟、强健可靠、稳定，有着极好的运行表现。
最重要的是，Web应用程序框架已经过实践的检验。
它已成功应用在生产企业应用程序中，每天为数百万用户服务，创造着数百万美元的收益，并已得到越来越多的企业开发人员、设计师和项目经理的认同。
基于上述及其他原因，以及Web应用程序框架已在企业中成功应用的事实，那些准备采用Web应用程序框架的企业完全可以相信，该框架符合企业级Web应用程序框架的所有标准。
28Web应用程序框架概述•2004年12月 第2章 Web应用程序框架设计和体系结构的常见问题 本章为初次使用Web应用程序框架的人员提供了有关Web应用程序框架设计及体系结构的常见问题解答。
本文档中包括的问题如下：■Web应用程序框架的适用对象？■拥有J2EE后，为什么还要使用Web应用程序框架？■难道Web应用程序框架不仅仅是另一个专用Web应用程序框架(JAPWAF)吗？■Web应用程序框架与其他J2EE框架有什么不同？■Web应用程序框架具有显示字段概念。
这不同于我所见过的J2EEBlueprints或其他 J2EE体系结构-为什么不直接从HelperBean中取值？■Web应用程序框架应用程序需要使用EJB吗？■Web应用程序框架应用程序是如何构造的？■如何实现请求流程和URL格式？■如何将视图Bean与会话或实体Bean关联起来？■将JSP范围设置为请求来简化线程安全编码并在每次请求时强制构造并破坏Bean， 这会有负面的性能影响吗？ Web应用程序框架的适用对象？ Web应用程序框架旨在满足J2EE开发人员的需要：要构建以增强中型、大型和超大型企业实力为目的的Web应用程序。
Web应用程序框架将强健可靠的设计模式与这些模式强健可靠的实现相结合，提供了一个企业Web应用程序的基础。
由于Web应用程序框架为可重用的类似于JavaBean的组件提供了核心设备，它也适用于那些想要提供可轻松集成到Web应用程序中的现成组件的第三方开发人员。
这些相同的功能使Web应用程序框架非常适于用作平台，构建垂直划分的Web应用程序或服务。
这是因为它的水平划分的扩展功能为最终用户和原始开发人员都提供了一个完善的方式，可以扩展或利用现有的垂直划分的功能。
29 拥有J2EE后，为什么还要使用Web应用程序框架？ J2EE是一个新兴的技术，尽管这项技术的出现非常令人振奋，但它还不能提供某些非J2EEWeb技术不断开发出来的丰富而快速的开发模型。
这不一定是件坏事情-不使用非标准应用程序API可以带来很多好处，而且J2EE提供的自由可以让许多Web开发任务变得更加轻松、快捷，结果也更容易维护。
但是，由于不断发展的行业需要尽快构建具有强大功能的Web应用程序，并且J2EE又将这类任务指定为最小级别，因此对于现实世界中几乎所有的Web开发项目来说，特别是企业Web应用程序，除了J2EE以外，仍然需要其他应用程序设计模式和附加功能。
这就是Web应用程序框架得以发展的原因：容易理解并接近本质，另外还提供了无与伦比的设计灵活性和一致性。
最重要的是，它完全基于纯粹的、符合标准的J2EE平台，因此您不必放弃J2EE才能使用Web应用程序框架。
相反，您可以从这两者中获益。
难道Web应用程序框架不仅仅是另一个专用Web应用程序框架(JAPWAF)吗？ 答案是否定的。
使用专用Web应用程序框架，您不仅要使用没有源代码的框架API，还要使用供应商提供的基本应用服务器平台。
如果您想要其中的一个而不需要另一个，那么很不幸，您需要将应用程序从一个供应商的解决方案转移到另一个供应商的解决方案，这意味着您需要从头开始编写应用程序。
Web应用程序框架则不同。
■Web应用程序框架完全基于J2EE平台。
在核心Web应用程序框架类中没有针对容 器的代码，这就意味着您可以在所喜欢的J2EE容器中使用Web应用程序框架而不需要进行更改。
Web应用程序框架已经在许多容器（例如ApacheTomcat、CauchoResin、AllaireJRun、SunJavaSystemApplicationServer、WebServer和IBMWebSphere）中进行了测试，它在所有容器中的用法都相同（除非容器存在错误，才需要稍微不同的用法）。
该框架已确定包含J2EE，并充分利用上述事实，且将您作为受益人。
■您拥有完整的Web应用程序框架源代码。
这意味着您可以调查、更改、修复、调节或配置框架中包括基础设计模式在内的每个细小的方面（尽管我们都希望将来可以不需要这样做），使其准确地满足您的需要。
我们建议您观察Web应用程序框架的工作原理，这不只是因为它将有助于更加快捷轻松地修复错误，而且还因为只有详细的技术性审查和讨论才能使Web应用程序框架从中获益。
■Web应用程序框架基本上是一个完全基于接口和对象协议的设计模式。
系统会提供这些接口的缺省实现，但是如果您不喜欢该实现的工作方式，可以覆盖不喜欢的部分。
或者，您自己重新实现接口来创建一个新类型的Web应用程序框架对象，此对象可以无缝地集成到框架的其余部分。
由于遵守相同的协议，新的Web应用程序框架对象可以与其他类型的Web应用程序框架对象进行交互式操作。
请在您首选的专用Web应用程序框架中尝试这项功能。
30Web应用程序框架概述•2004年12月 Web应用程序框架与其他J2EE框架有什么不同？ 如果仔细研究J2EE框架，就会发现：在创建Web应用程序框架前后，其他J2EE框架通常不能满足企业J2EE开发人员的各种需求。
相反，这些框架仅尝试满足有限的企业开发需求，因此，当用来构建现实世界中较大的企业Web应用程序时，这些框架就显示出不足。
也许最常见的故障主要集中在JSP显示和标记库上。
ApacheStruts可能是此类框架中最有名的示例。
尽管JSP是所有J2EEWeb应用程序的固有部分，且标记库对于减少JSP制作成本至关重要，但是它们不能成为试图最小化开发人员的工作量，同时又最大化应用程序可维护性（两者对于现实世界中的企业开发都至关重要）的框架的主要焦点。
例如，JSP中任何类型的程序构造都存在维护问题，这是因为程序构造会将应用程序功能暴露给JSP制作人员，还因为并行内容必须在许多潜在位置复制此功能。
另外，这些结构很少能够像Java代码那样丰富或功能强大，这样会导致一个更严重的问题，即需要在JSP中创建小脚本以处理复杂但相对常见的问题。
ApacheStruts专注于这种应用程序的开发，它的许多功能将实现此类功能作为目标。
对于不需要显著维护或扩展生命周期的中小型应用程序来说，尽管这些类型的功能可能带来较高的生产率，但是很显然这样的应用程序在企业中并不是典型的。
比较而言，Web应用程序框架认识到了JSP的优点并加以充分利用，而没有降低可维护性或应用程序开发人员较好控制JSP显示的能力。
它通过将视图层分为显示规范(JSP)和显示逻辑组件（视图组件）完成这些目标。
因为这些实体的组合会将程序构造同时保持在JSP之外，其中构造将与内容混合在一起，因此很难维护，尽管可以通过使用设计仔细的与视图相关的事件对显示提供更多控制。
其他框架的另一个常见故障是缺少连接至后端组件的模型或视图层接口的正式概念。
对于要快速构建可扩展Web应用程序的开发人员来说，在表示应用程序数据的视图组件和生成该数据的组件之间必须有一个明确的协议。
一般来说，在其他框架中没有这样一个协议或接口的规范，以致开发人员不得不以视图层的特定格式（例如一个具体的对象实例）提供数据，或者编写冗长的代码来处理从后端到视图的数据。
如果给定的是一个小项目，或者一个将来不需要对其后端层进行更改的项目，这将是可接受的。
而Web应用程序框架通过其模型接口在视图和后端之间提供了一个正式协议，使视图组件可以完全独立于后端组件。
此功能也使开发人员可以无缝地更改与视图关联的后端而不用更改视图本身。
这意味着在应用程序生命周期的早期，视图可以直接通过SQL查询显示，但是随着应用程序企业层的完善，就通过EJB显示数据，在所有这些操作中视图组件并不知道这种差别。
由于此原因，Web应用程序框架提供了一个完整的模型视图-控制器体系结构，而大多数其他框架实际上仅提供了一个视图-控制器体系结构。
最后，其他框架通常不考虑Web应用程序的提交周期，因此也不指定应用程序组件之间的互连和关系，难以维护。
这种忽略给开发人员带来了负担，不幸的是，当项目开始时，这种负担可能不会轻易显露出来。
例如，尽管许多框架为外出数据提供了结构，但很少或不会为外来数据提供结构，以致调用的组件被迫在“黑暗”中工作，不能确切知道在给定的请求调用上所接收到的数据内容。
第2章Web应用程序框架设计和体系结构的常见问题31 另外，指向相同组件的多个应用程序路径强制将目标组件所需的数据准备传输给调用者。
由于对象之间的依赖关系激增，这将大大妨碍可维护性。
通常，这种关系的激增反映为低级控制器逻辑的激增，用户需要手动将输入数据转移到目标组件或后端。
这可能导致显示页面时使用后端组件或模型，但处理来自先前显示页面的请求时并不直接使用它们的一种不对称性。
这种不对称给开发人员微管理后端组件造成了更大负担，并且会忙于处理Web应用程序容器中运行的低级细节。
相反，Web应用程序框架将此类功能合并到它的核心设计模式和实现中。
这可以将开发人员完全从显示视图和后备模型的数据传入和传出中解脱出来。
结果是，从开发人员的角度来看，模型在请求之间保持有状态但不会将实际状态负担强加给不会变化的应用程序。
简而言之，Web应用程序框架满足了企业开发人员的各种需求，从而避免了仅关注某一项技术或某一部分需求。
其他框架往往会采取可能满足企业开发的一个或两个方面的有限方法，但是很少能满足构建现实世界大规模的企业Web应用程序所需的所有关键方面。
Web应用程序框架具有显示字段概念。
这不同于我所见过的J2EEBlueprints或其他J2EE体系结构为什么不直接从HelperBean中取值？ 显示字段范例为更多原始技术提供了独特的方便。
在解释这些方便之前，请注意不要按照想象在应用程序中使用显示字段。
容器和子视图机制完全是基于可嵌入任意视图对象的概念。
子视图对象可能与整个的购物车显示或应用程序菜单一样设计得粗糙，也可能与独立显示字段一样设计得仔细。
该灵活性允许应用程序根据模块化部件进行组合，其中包括更加传统的面向显示字段的方法。
简而言之，您可以直接从Web应用程序框架的HelperBean中取出值，但是您可以确信一定有更好的方式。
每一个顶层ViewBean实例（或根视图）是ContainerView的一个实例，可以包含任意子视图集，某些子视图可以是显示字段视图。
TiledView也是子视图，除本身包含子视图之外，也可以任意嵌套。
视图的这种分层结构在某种程度上要比一般Web层开发人员所期望的复杂。
例如，许多此类开发人员可能只创建一个HelperBean，此HelperBean声明了所有必要的方法以获得所需的值，对相应的JSP进行显示。
这些值的源可能被封装在HelperBean的方法内。
他们可能使用
此操作很简单，但对于开发和维护却存在某些明显的不足。
尽管Web应用程序框架很相似，但子视图的使用对于维护精确的模型视图分离很重要。
例如，所有显示字段视图都绑定到一个模型。
这些视图不具有值的概念。
而且，所有显示字段现在均绑定在一起，尽管并不是所有显示字段均为数据绑定。
在某些情况下，此模型是DefaultModel的一个实例，只是内存中存储。
在其他情况下，绑定模型可能是SQL查询、存储过程、EJB、业务对象、XMLDOM或SOAP过程。
显示字段视图将与数据和业务行为的存储和管理完全分离。
32Web应用程序框架概述•2004年12月 显示字段也不知道所绑定的模型，因为显示字段可以绑定至任何模型，并且进行操作时无需知道该绑定模型的类型。
这意味着您不需要编写应用程序代码，就可以将值从值源转移到值的使用者（这一过程称为数据转移）。
相反，在Web应用程序框架中可以轻松地进行此操作，不同于在单纯的HelperBean环境中，在这种环境中您还需要在每一个Bean的取值函数中编写并维护针对目标的代码，才可以从EJB、JDBC、ResultSet等中获取值。
简而言之，显示字段提供了允许任意模型进行无缝插接的最小间接需求。
而且，由于显示字段与其关联模型通过通用模型接口发生交互式操作，后端数据可以用其本地格式表示，而无需占用很多资源处理仅视图层所需的数据格式。
另外，显示字段将显著改进通过典型的HelperBean/标记库方法创建的编程模型。
显示字段不但允许通过控制逻辑进行直观操作，而且还提供了针对类型的操作和HTML显示接口，这两种功能不可能通过其他方法实现。
例如，典型标记库方法的缺陷之一是HelperBean没有HTML显示进程的实际输入。
如果需要控制此显示，此故障通常会导致JSP中与应用程序相关的大量逻辑和属性成为小脚本。
例如，您可能需要跳过某个字段的显示，因为当前用户未经授权不能查看该显示。
在典型的JSP中，开发人员必须提供小脚本包围该显示，小脚本会将Java代码放入JSP中。
另一个方法是：增强标记处理程序以便按照某些标准机制调整其显示，这类似于检查条件变量。
使用这两种方法产生的问题是：与应用程序相关的数据和与显示相关的数据之间没有一致性或分区。
换而言之，它缺乏简洁性并难以维护。
Web应用程序框架通过提供两个方法中最佳的方法来处理此限制问题。
例如，要调整字段显示或自定义字段的HTML输出的开发人员最终可以在父视图中实现显示事件处理程序，而该处理程序在HTML显示过程中会被自动调用。
然后，开发人员可以跳过该字段的显示，或者直接操作HTML输出（例如，将文本框改成纯文本）。
或者，开发人员可以调用表示必要操作的显示字段视图上的方法，当字段由HTML显示子系统（JSP/标记库组合）显示时，将自动考虑到此操作。
因此，开发人员不需要将与显示相关的代码连同页面内容一起放入JSP、控制业务逻辑或面向业务的模型中，而可以增加显示字段显示进程或者轻松指向它。
这不仅可以将Java代码保持在JSP之外，而且要远比小脚本或其他控制HTML显示的方法功能更强大。
另一个益处是它能够更加一致。
显示字段还允许开发人员可以将HTML页面用作服务器端的状态对象。
当用户单击HTML页面上的按钮或HREF时，请求最终会路由回显示该按钮或HREF的视图，并且会调用对应于该对象的事件处理程序。
但是，在调用事件处理器之前，Web应用程序框架会使用提交的请求参数重写所有的显示字段和视图。
结果是，从开发人员的角度来看，页面保持有状态并且只响应来自用户的命令。
在很大程度上，开发人员处理事件的方式与在胖客户端应用程序中处理事件的方式相同，方法是实现事件处理程序并且基于请求及其更新字段值采取操作。
由于显示字段一直绑定到模型中，因此对字段中的值所进行的任何更改都将自动反映到模型中。
这使开发人员可以在类似于传统胖客户端和类似于正式MVC编程式样之间选择最有效的折衷方案。
注意到使用HelperBean和使用显示字段两种方法中的任何一个都可以实现虚包设计模式非常重要，因为进出HTML页面的接口是由这些对象处理的。
由此接口提供的数据值可能来自许多源（包括多个后备EJB、业务对象、结果集等等），在抽象术语中，这 第2章Web应用程序框架设计和体系结构的常见问题33 些都可以作为模型。
但是，鉴于传统HelperBean通过自定义代码管理这些模型，很少或不具有一致性或可复用性，Web应用程序框架将这些模型抽象为模型的正式定义，并且在模型和绑定到模型的视图之间指定了一个清楚的协议。
这个正式协议具有以下优点：■它允许显示字段在由视图表示的虚包和作为此虚包后备的模型集之间提供灵活的映 射。
由于Web应用程序框架中包含了基于XML的声明功能（已经在进行中），显示字段将允许对此虚包进行声明更改，这将大大简化应用程序开发并显著减少开发时间。
■由于此虚包可以轻松地进行更改，使用声明支持而无需重新编译就可以相当轻松地将对后备模型的更改反映到应用程序的视图部分。
此方式与传统HelperBean方法比较起来，在传统方式中开发人员可能需要向其HelperBean添加存取函数和赋值函数，或者修改所需的代码以便从后备模型中获取值或向后备模型发送值。
由于这些经过仔细设计的更改及其所需的重新编译，将显著增加开发时间，降低工作效率和对象的重复使用。
Web应用程序框架应用程序需要使用EJB吗？ 答案是否定的。
与任何其他J2EE应用程序一样，您可以获得EJB的引用并在Web应用程序框架应用程序中直接使用此引用。
但是，尽管EJB是J2EE的一类组件，但并不是必需组件。
而且，对于应用程序体系结构来说，EJB是相对复杂的附件，当前还有某些明显的缺陷。
由于基于EJB的体系结构提出了许多独特的挑战，并要求在应用程序设计和实现的许多领域进行大量的附加投资，因此多数Web开发人员不准备使用此结构。
因此，要求使用EJB可能会带来问题。
但是，使用EJB是会得到支持和帮助的。
Web应用程序框架提供了基于灵活的和可插接式模型-视图体系结构的有价值的功能，此体系结构与面向Web和面向EJB的应用程序都兼容。
作为直接使用EJB的一种替换方法，开发人员可以使用由EJB备份的或直接实现的模型。
EJB的集成与Web应用程序框架中任何其他类型的模型一样都是无缝的，并提供自动数据绑定和其他高级功能。
Web应用程序框架中包含了一个名为BeanAdapterModel的类作为开始使用EJB的方法，该类将标准的模型接口映射到任意JavaBean属性上。
如果拥有用户EJB，您可以将其打包装入此适配器模型，使显示字段可以直接访问其属性/值，而无需任何附加代码。
使用此适配器，从显示上的用户Bean对值进行显示并自动将值推回提交上的Bean中。
您也可以使用该类将访问打包装入本地业务对象-适配器不会关心其封装的对象是远程的还是本地的。
Web应用程序框架应用程序是如何构造的？ Web应用程序框架应用程序是由一个或多个模块组成的完全独立的实体。
每个模块是整个应用程序的一个功能片或逻辑组。
一个应用程序中至少需要一个模块，但是其他模块是可选的并可随时添加。
34Web应用程序框架概述•2004年12月 每一个Web应用程序框架应用程序都定义了称为应用程序Servlet的类，这是一个基类，可以由此基类派生出所有针对模块的Servlet。
应用程序的客户端仅访问模块Servlet。
应用程序Servlet仅作为通用基类为模块Servlet提供服务，并为在单个类中合并通用应用程序级别的事件处理器提供机会。
模块Servlet会考虑到这些事件仅用于模块的特殊性。
这些Servlet一起形成了每一个Web应用程序框架应用程序的请求处理框架结构。
每一个模块都对应了应用程序的一个子软件包，除了包含针对该模块的一个最小化Servlet框架结构之外，还包含一个或多个逻辑页面。
每一个模块可能还包含支持模块和其他非Web应用程序框架类（当然，模块中的类通常也可以使用此模块之外的类）。
模块中的每一个逻辑页面都至少包含一个JSP和一个ViewBean。
ViewBean是相应JSP的HelperBean，它和Web应用程序框架标记库一起提供了显示/应用程序事件框架结构。
每一个ViewBean都包含可重复使用子视图对象的任意分层结构，将这些对象汇编到可以在几分钟内创建完全合格的和数据绑定的页面。
如何实现请求流程和URL格式？ 所有请求最初都由控制器Servlet处理（每一个模块拥有一个Servlet，每个应用程序拥有几个Servlet），由开发人员选择此Servlet的URL。
此Servlet将请求分发到针对请求的控制器对象(ViewBean)，然后此对象会将请求转发到另一个资源（JSP、ViewBean或其他Web资源）。
Servlet的源代码及其分发机制完全在开发人员的控制之下，所以鼓励开发人员通过阅读精心注释的源代码学习此机制的详细资料。
如何将视图Bean与会话或实体Bean关联起来？ 它们之间没有直接的关系。
视图Bean是一个JSP工作或HelperBean(usebean)。
每一个视图Bean都充当其对等JSP的中心支持。
如果需要，会话和实体Bean可以通过视图Bean或其关联的模型或视图访问。
将JSP范围设置为请求来简化线程安全编码并在每次请求时强制构造并破坏Bean，这会有负面的性能影响吗？ 一般而言，支持持久性应用程序对象的系统开销明显高于使用当前方法的系统开销。
测试表明，与专用的非J2EE容器先前所需要的系统开销以及典型的Web应用程序所需的系统开销比较起来，当前方法产生的系统开销很小。
实际上，新型JVM中的对象分配占用资源很少，这就证明了此方法的价值。
但是，这并不意味着已忽略了这种方法的系统开销。
第2章Web应用程序框架设计和体系结构的常见问题35 尽管某些非J2EE容器为了提高效率提供了持久性应用程序对象，但是这些对象对于客户端来说并不是有状态的。
因此，每一个客户端的状态信息必须在每个请求上重新生成。
等效的应用程序对象已经经过了仔细设计，并尽可能减少系统开销。
在大多数情况下，这就相当于在任何情况下都必须重新创建每一个请求的有用的状态信息。
另外，Web应用程序框架支持对这些对象的优化访问，因此仅在需要时才创建这些对象。
所以说在大多数情况下，基于Web应用程序框架的应用程序在处理和内存消耗方面总体上要比非J2EE应用程序明显有效。
设计一个有效使用持久性应用程序对象的框架结构是不可能的。
SunJavaSystemApplicationServer和其他高度可伸缩的Servlet容器都使用多个JVM，用户的请求不必路由回相同的地址空间。
这意味着在任何情况下必须重新初始化每一个请求的持久性应用程序对象。
此操作的系统开销至少不会少于再次简单创建对象的系统开销。
另外，将应用程序对象放到会话中并不十分可行，由于它占用很多资源并且至少需要解序列化，解序列化比简单的对象分配更昂贵。
将功能层添加到Web应用程序框架中以支持持久性应用程序对象，会将开发人员从基本容器中完全分离出来。
此操作通常违反了尽可能接近标准J2EE的设计原则。
尽管已产生了这些缺陷，但是在将来如果益处大于缺陷，仍然可以提供使用持久性应用程序对象的功能。
然而，目前这种功能仅适用于小范围内的应用程序，而对于典型的Web应用程序框架应用程序是没有帮助的。
36Web应用程序框架概述•2004年12月 索引
A API（J2EE以前）,11
B BluePrints样例,J2EE,17本书的组织结构,6标记库,19表示层模式,至少实现J2EE,17并行内容,支持,25
D 调试（J2EE以前）,12顶层软件包,18对称显示,21
F 分层视图和组件范围,24分层虚包,19服务到工作者委托,12
G GUI开发,胖客户端和瘦客户端,12概述,技术,18概述,应用程序框架,11至28高效的对象管理,25工具准备,27功能,高级和低级,13功能,开发高级的,15 功能,类型,17功能,易于使用,高级,26
J J2EE应用程序框架,出现,12JSP范围设置为请求,35JSP页,基于HTML的,19
K 开发人员没有经验的,14有经验的,14 开发人员,第三方,15开发人员,新J2EE,15可维护性,14框架,企业,13
M 模型-视图-控制器(MVC)模式,17
P 胖客户端GUI开发,12
Q 企业级性能,27前言,5至9请求流程和URL格式,如何实现,35 37
S Servlet体系结构,类型I和类型II,12 设计模式分发程序视图,16复合实体,16复合视图,16服务到工作者,16服务定位器,16服务激励器,16会话虚包,16快速道读取器,16拦截过滤器,16命令,17模型-视图-控制器,17前台控制器,16适配器,17视图帮助器,16使用,16数据访问对象,16业务委托,16值列表处理器,16传送对象,16传送对象汇编程序,16 设计师,企业,14视图Bean和会话或实体Bean关联,35瘦客户端GUI开发,12
U UI,基于MVC的,12
W Web应用程序构建的挑战,11 Web应用程序,大规模企业,12Web应用程序框架 不做什么,15发展,14功能,15工作原理,16基于J2EE标准,20仅仅是另一个专用Web应用程序框架(JAPWAF) 吗？,30 面向J2EE开发人员,15设计和体系结构的常见问题,29适用对象,15,29为什么不从HelperBean中取值？,32为什么不使用J2EE,30应用程序是如何构造的？,34应用程序需要使用EJB吗？,34与其他J2EE框架有什么不同,31与其他Web应用程序框架的区别,20
X 线程安全编码,35性能,13
Y 一致性,应用程序,13应用程序,Web,J2EE以后,12应用程序,Web,J2EE以前,11应用程序开发模型,中小型,13应用程序框架 企业的标准,13应用程序事件,23应用程序一致性,20
Z 正式的模型实体,22子软件包,19组件,构建可重复使用的,15 38Web应用程序框架概述•2004年12月
声明：
该资讯来自于互联网网友发布，如有侵犯您的权益请联系我们。
