应用程序java实用教程

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