基本信息
- 原书名:Core J2EE Patterns: Best Practices and Design Strategies, Second Edition
- 原出版社: Prentice Hall PTR
- 作者: (美)Deepak Alur,John Crupi,Dan Malks
- 译者: 刘天北 熊节等
- 丛书名: Sun公司核心技术丛书
- 出版社:机械工业出版社
- ISBN:9787111159421
- 上架时间:2005-4-18
- 出版日期:2005 年3月
- 开本:16开
- 页码:500
- 版次:2-1
- 所属分类:计算机 > 软件与程序设计 > JAVA(J#) > J2EE

编辑推荐
"没有这本书,就别开发EJB。"一部由Grady Booch(Rational软件公司首席科学家)和Martin Fowler(ThoughtWorks首席科学家)等大师们写序并且担保的作品。这些足以确认《J2EE核心模式》这本书在其领域中舍我其谁的地位。
内容简介
计算机书籍
"Java世界中各种类库、工具和技术规范俯拾皆是。而把这些内容融合在一起、解决真实问题的专业知识却一直竟告阙如。本书中的这些模式正是J2EE软件构建过程中的智力水泥。"
--John Vlissides,《设计模式》的作者之一
"《J2EE核心模式》的作者们提取了一组真正实用的模式。他们介绍了应该如何应用这些模式、如何重构系统以便从模式中获益。拥有这本书就像有一个专家组坐在你旁边一样。"
--Grady Booch,Rational软件公司首席科学家
"作者们介绍了大量对于应用程序架构极有帮助的模式,这是一项了不起的工作。单单是书中的'重构'部分就值整本书的价钱!"
--Craig McClanahan,Struts首席架构师,JavaServer Faces技术规范组负责人
开发者们常常把"学会一种技术"和"学会使用这种技术进行设计"混为一谈。在本书中,Sun Java中心的资深架构师们分享了他们多年积累的使用J2EE技术进行设计的经验。
作译者
John Crupi是Sun Java中心的杰出工程师和首席Java架构师。他有17年以上的分布式对象开发经验,他的主要研究兴趣在于创建可重用的,可扩展的J2EE架构,以及进一步提升J2EE模式的水准。
Dan Malks是Sun Java中心的主任工程师。他有16年以上的开发经验,他的主要研究兴趣在于面向对象技术以及这种技术在企业级的,基于Web Service的项目中的应用。他发表过很多作品,其中既有在行业杂志上发表的论文,也有讨论Java、J2EE技术以及模式的专著。
目录
第一部分 模式和J2EE
第1章 导论
什么是J2EE
什么是模式
历史回顾
模式的定义
模式的分类
J2EE模式目录
演化过程
怎样使用J2EE模式目录
使用模式的益处
模式、框架和重用
小结
第2章 表现层设计考虑和不佳实践
表现层设计考虑
会话管理
控制客户端访问
验证
助手类属性--完整性和一致性
译者序
当然,对于广大中国开发者而言,我们早就已经在"没有这本书"的条件下开发了大量J2EE乃至EJB应用系统。那些波折的、不乏磨难的开发历程似乎使不少人具备了一种不无理由的自信,在掌握了若干API细节、若干应用服务器配置诀窍、若干框架类库用法之后,他们或是公开、或是暗自地把自己当成了当之无愧的Java企业开发专家。--不,这些话没有任何揶揄的意思:我们想说的其实是,本书恰恰是为以上这一类开发者写的。对于他们想成为"Java企业开发专家"的隐秘欲望,本书就是最大限度的补救和成全。如果说,此前的各种教程都是在介绍J2EE开发中的"内容"要素--也就是,教给我们"做什么"的话,本书关注的则是这里的"形式"要素,即"怎样做"才能开发出高效的、优雅的J2EE系统。读者从中学到的,将不仅仅是"J2EE技术",而是"如何使用J2EE技术进行设计"。
换句话说,如果你以前没有进行过J2EE实践,但明早将应聘一个需要"1年J2EE开发经验"的职位,本书中不包含你今晚要彻夜吞咽的那一类知识;相反,如果你,这位未来的"Java企业开发专家",追求的职位是"资深Java应用系统架构师",如果你预料到未来的上司明天将问起"怎样实现访问控制"、"何时采用细粒度的接口设计"等"高阶"问题,那么恭喜你,今晚--乃至今后--阅读本书,你选对了补课的读物。
作为本书第1版的忠实读者,我们(半是欣喜、半是惊讶地)发现,眼前的这部第2版构成了全新的阅读体验。作者们按照最新版J2EE技术规范(尤其是EJB 2.1)全面修订了技术细节;根据模式社区的研究交流,作者们补入了若干模式;即使是一些不涉及技术更新的部分,论述方式、示例也完全不同于第1版;原有的PSA项目(第1版"尾声"一章)融入了其余各章的"示例代码"部分;而新增的讨论"微架构"的尾声、对Web Service等技术的关注、对各种的持久化方案(定制持久化、EJB、JDO等)的深入讨论,都体现出作者们对本书新版的大量投入。
受益于本书有年,在此,我们想冒昧地为本书的中国读者们建议一条高效的阅读路径:与第1章相比,第5章"J2EE模式概览"是读者更合理的起步点。请特别关注其中对"分层"、"术语"和模式/策略区别的讨论,这些都是贯穿全书的重要概念!其次,应该通读第2章"表现层设计考虑和不佳实践"和第3章"业务层设计考虑和不佳实践":即使你不打算使用任何模式,甚至,即使你根本不关心J2EE开发,只要你的工作与分布式企业应用系统有关,这两章涉及的问题都是你迟早会遇到的。至于每个具体模式本身,我们则推荐读者留意其中详尽的"策略"部分和那些散布其中的"设计手记"。前者讨论了对同一个模式的多种实现方案,后者则突出介绍了特定开发领域的一些核心概念和考虑。
一部英文技术论著在汉语中的旅行,永远是一段难以捉摸的行程。对于本书的汉语译者,"技术难度"并非挑战:全书讨论的正是译者们最为熟知的一个领域,所以我们能够负责任地说,在这个中译本里,没有任何技术细节会因为译者的无知或生疏而发生变形或曲解。这次翻译的原则和前提是对原文的彻底领会。事实上,译者在翻译工作中遇到的困难主要发生在"语汇"层面。简单地说,J2EE专著的译者总要面对"翻,还是不翻"的两难处境:对象、函数的名称,UML图中的各种元素,这些内容由英语表示早就是约定俗成,即使是英语程度略低的开发者大概也都能读懂,所以,在读者能够理解的部分尽可能保留原文似乎是一种合理的做法--毕竟开发工作最终是与代码有关,而代码则肯定是要用"英文"的。但在另一方面,翻译的责任就在于让不谙英文的读者也能通达作品,如果译文中大量段落(不包括示例代码)都仍保留为英文或"类英文",那么读者也就无法直观地获得原文包含的信息。反复权衡之后,在这个译本中译者的解决方式还是折衷的。工作中我们采取了以下原则:
1)术语尽可能采用通用文献定译,不自创译法。对于各个模式的名称、模式文档模板各部分名称、重构手法名称,我们参考了李英军等译《设计模式》(机械工业出版社,2000年)、熊节等译《重构》(中国电力出版社,2003年)等译作,以及IBM Developer Works中文网站的部分资源。
2)本领域的一些常见术语,如果没有定译,本书也不自创新语,强译为中文,而是保留英文原字。这一类的术语包括:applet、servlet、bean、JavaBean、entity bean、session bean、EJB、finder、Context、cookie、RowSet、null、scriptlet、Web Service。根据我们的观察,国内的开发者在日常工作中已经习惯按原文使用以上术语。在一些情况下,我们也以注释形式澄清了这些术语的用法。另外,一些非常直观的英文表达方式,比如"versus/vs"("A versus B"即"A对B"、"A与B相比较/对照"),我们也径用原文--改为汉语既罗嗦,也不直观。
3)模式中的对象名称,往往按照代码风格命名,比如"Business Object"、"CustomerTO"等。如果对此完全不加翻译,那么很多充斥这类表达的段落就很难理解。我们的原则是,在每个自然段第一次出现某个这类表达方式时,用括号注明,比如"BusinessObject(业务对象)"、"CustomerTO(客户传输对象)"等。希望这个做法能够维持易懂和简洁之间的平衡。
4)书中示例代码占有相当大的比重,而代码注释则是理解这些代码的关键。我们把所有代码注释译为中文。而对在视图中显示特定结果的代码(比如调试信息等),我们没有改为中文,只是在必要时对输出信息的含义加以注解。如果读者更信赖代码原貌,还可以从本书官方网站http://www.corej2eepatterns.com/下载原始代码。
5)原书不包含注解,目前的所有注解都是译注。
6)原书申义未畅处,译文中以方括号[]加以解释、补足,略去生涩。这与上面三条原则一样,都类似于在原作讲话时的插嘴--但翻译任务本身,似乎本就已经是一种"插嘴"了。在博学的读者看来,有时候译者或许还不如保持体面的沉默--但我们只能力图做到插嘴而不多嘴。
7)原书引用了Apache项目的若干代码,所以附录中包含Apache软件授权协议一页。中译本照录了这份法律文件,未加翻译。
8)几个关键术语的译名考虑:
·application:一般译为"应用程序"或"应用"。本书中这个词单独出现时,往往指的是"企业应用",亦即企业信息应用系统。考虑到"应用程序"容易被理解为"桌面程序(desktop application)",在该词含有"企业应用"意味时,我们译为"应用系统",其他情况下则译为"应用",以示区别。
·client:译为"客户端"。但本书中所说的"客户端"常常是指特定组件的调用者,不一定是"桌面程序客户端",反倒很可能本身也是另一种组件、甚至一个子系统。希望读者注意该词在书中的用法。
·POJO:软件方法论大师Martin Fowler在《Patterns of Enterprise Application Architecture》(PEAA)中创造的说法,是plain old Java object的缩写,指普通Java对象(而不是EJB等组件)。中译本仍采用"POJO"名称。
·enterprise bean:直译为"企业bean",在本书中就是"enterprise JavaBean/EJB"的另一说法。为了直观,我们统一译为"EJB"。
·tier/layer:字面上都是"层"/"层次"。本书中"tier"指的往往是"架构"意义上的分层,比如"表现层","业务层"、"集成层"等,而"layer"既分享了前者的含义,有时也指tier内部的中间层次,比如"会话门面"就构成了客户端和业务服务之间的一个"layer"。这两种意思实在很难区分,中译本只能都译为"层"、"层次"。希望读者在阅读中体察这种细微差别。
·delegate:是设计模式中的重要概念。一般译为"委派"。但在我们看来,这个译法还不完整,因为"委派"在汉语中只是动词,而delegate往往还充当名词。这次中译本的做法是,动词delegate仍译为"委派",比如"A把功能F委派给业务层的B",而名词delegate则译为"代表",比如"B是A在业务层的代表"。希望读者体察,并推荐更好的译法。
前言
我们完全修订、更新了最初的15个模式,使得本书覆盖了J2EE技术1.4版的规范。我们在这些最初的模式中加入了很多新的策略。另外,我们还记录了6种新模式,以便改进模式语言,为构建、理解、使用J2EE框架提供更好的概念抽象。虽然这些模式中的每一个本身都极为实用,但我们还进一步相信,当开发者将其组合起来解决大型问题时,它们更能显出威力。因此在本书的新版中,引入了一个我们正在探究的、与此相关的全新领域,我们称此为"微架构"。
所谓"微架构",就是搭建应用程序和系统的积木块。与列入目录的那些单独模式相比,这个概念是一种更高层面的抽象,它常常表现为一组相互关联的模式组合,用于解决在应用架构中经常重现的一些共通问题。
我们乐于把"微架构"当作一种由相互关联的模式组成的网络,由此形成一种现成的解决方案,用于解决一个粒度更大的问题,比如子系统的设计。
本版中包括了一个叫Web Worker的微架构。它所解决的问题是:一个J2EE应用怎样与一个工作流系统集成。它特别讨论了使用系统集成模式让工作流系统中的用户与J2EE应用进行交互的问题。
本书讲述的是Java 2企业版平台(J2EE)的模式。本书新版中记录的J2EE模式,能够用于解决在J2EE平台下进行软件应用开发的设计者常常遇到的那些问题。在这个模式目录中记录的模式都是在设计实战中发现的,正是因为使用了它们,我们才能为自己的客户创建出了成功的J2EE应用。
本书描述了很多在J2EE平台下证明可行的解决方案,重点强调了以下核心J2EE技术:JavaServer Pages(JSP)、servlet、Enterprise JavaBeans(EJB)组件、Java Message Service(JMS,Java消息服务)、JDBC以及Java Naming and Directory Interface(JNDI,Java命名与目录接口)。对于那些在J2EE平台下经常重现的问题,我们通过J2EE模式目录和J2EE重构给出了解决方案。在开发新系统或是改进现有系统的设计时,你可以应用这些想法。本书记录的这些模式能够有助于你迅速熟练地掌握J2EE技术,从而构建出健壮、高效的企业应用。
今天,正如以往一样,我们中间有很多人天真地以为,学会了一种技术,也就等于是学会了用这种技术进行设计。诚然,对于利用某一技术进行设计来说,懂得这种技术是成功的重要元素之一。但现在有很多Java图书,对技术细节(比如API的一些专门用法等等)做出了出色的讲解,但对如何应用这种技术却未作深入考察。要想学会设计,就需要实际设计经验,需要和其他开发者一起分享关于最佳实践和不佳实践的知识。
本书中传达的经验来自我们的工作实战。我们属于Sun公司的Sun Java中心(SJC)咨询机构。在工作当中,我们经常遇到一些情况,因为技术发展过于迅速,设计者和开发者都仍然在奋力理解技术本身,而无暇理解如何使用该项技术进行设计。
因此,简单地告诉设计者和开发者怎样写出优秀代码,或是建议他们使用servlet和JSP开发表现层,用EJB组件开发业务层,这都是不够的。
那么,在这样的情况下,一个热心的J2EE架构师又怎样才能不单单是学到"做什么"、还能学到"不做什么"呢?哪些实践构成了最佳实践?哪些是不佳实践?怎样完成从问题到设计,再到实现的整个过程?
Sun Java中心与J2EE模式目录
从初创时期以来,Sun Java中心的架构师们就在与来自全球的客户一起合作,致力于成功地设计、规划、构建、部署各种不同类型的基于Java和J2EE的系统。Sun Java中心是一个快速成长的咨询机构,一直在招募新员工,加入它经验丰富的架构师队伍。
目前已经有大量已验证有效的设计和构架,将这些设计经验固化下来并和其他人一起分享,是我们行业的一项重要需要。我们很早就认识到了这种需要,从1999年就开始以模式的形式记录我们在J2EE平台下的工作经验。虽然我们翻阅了各种现有文献,却没能发现有哪个模式目录是专门记载J2EE平台下的模式的。有很多书论及J2EE技术中的一种或多种,出色地介绍了技术,剖析了技术规范中的微妙细节。我们发现其中有些书还提供了一些设计上的考虑思路,因此也特别有益。
在2000年6月的JavaOne大会上,我们第一次公开发表了我们关于J2EE模式的想法。从那以来,我们收到了来自架构师和开发者的大量热忱反馈。其中一些人表示特别乐意进一步学习模式,还有一些人则说,他们使用过这些模式,只不过没有加以命名、也没有记录下来罢了。人们体现出来的对J2EE模式的兴趣鼓励我们进行进一步的工作。
因此,我们整理出了J2EE模式目录,在2001年3月,这个目录的beta版通过Java开发者联盟(JDC)首次公布给了J2EE社区。基于整个社区的大量反馈,那一份beta版的文稿最终发展成了你现在见到的这本书。
我们希望这些在J2EE平台下的模式、最佳实践、策略、不佳实践和重构能让大家从中受益。
本书的讨论范围
本书讨论的内容包括:
·在J2EE平台下使用模式。
序言
那些深刻的、真正有用的模式大多都是很古老的东西,见到这么一个模式的时候,你往往会说:"嘿,我从前就这么做过。"但是,只有当专家为这个模式命名之后,你才获得了一整套讨论这个问题的语汇;此前,由于缺乏这种语汇,你往往想不到怎样使用这个模式,因此命名有助于我们更好地应用模式。最终,这样一个模式的功效在于,它能让你的系统变得更为简单。
而模式还不仅有助于构建更简单而又实际有效的系统,它们还有助于构建优美的系统。在一种极度缺乏时间的文化氛围中,编写优美的软件常常是不可能的,这是很可悲的事情。因为,我们作为专业人士,本来都应该致力于构建高质量的产品。而通过应用一组恰当的模式,你就有可能为自己的系统注入某种程度的优雅--缺乏模式的帮助,这种优雅往往就无从谈起。
《J2EE核心模式》的作者们提取了一组真正实用的模式。别误解我的意思:J2EE当然是一种重要的软件平台,它能够让开发团队构建出特别强大的软件系统。但是,目前的现实却是,在J2EE提供的抽象层次、服务与开发团队必须构建的最终应用之间,还存在着非常巨大的语义断裂,本书描绘的这些模式,事实上正是人们一次又一次用来填补这种断裂的共同解决方案。应用这些模式,也就是采用了一条最主要的避免软件风险的措施:只要编写更少代码就能获得相同的效果。你也不必再重新自己动手寻找解决方案,这些模式已经在很多现存系统的应用中得到了验证,所以只需应用它们就是了。
作者们不仅完成了一组模式的命名,还利用UML确定了模式的语义,使它们更容易为人理解。并且,他们也介绍了应该如何应用这些模式、如何重构你的系统以便从模式中获益。再说一遍,拥有本书就像一个专家组坐在你旁边一样。
Grady Booch
Rational软件公司首席科学家
Martin Fowler序
在1998年末,我所在的ThoughtWorks公司就开始使用J2EE了。在那个时候,我们发现了很多很酷(虽然有点儿不成熟)的技术,但是很少有人能说明怎样才能恰当地应用这些技术。也许是因为我们具备在其他OO服务器环境下编程的大量经验,所以我们自己能够应付这些问题。但是我们也见到很多客户费尽了周折--并不是因为技术本身的问题,而是因为不知道怎样才能恰当地应用这些技术。
使用模式,能够固化设计经验--也就是说,模式有助于将经常重现的问题的实际解决方案进行归类、编目。多年以来,对于模式的这种用途,我一直都是个由衷的爱好者。最近的几年里,业界的很多先驱者都在使用J2EE,都在寻找构成一个有效的J2EE解决方案的核心模式。本书对这些模式进行了出色的汇集,其中揭示的很多技术都是我们自己通过多次尝试、多次错误才获得的。
这也就是本书的重要之处。对API倒背如流是一回事;知道如何设计优秀的软件则是另一回事。本书确实致力于固化这一类设计知识,这也是我见到的第一本这么做的书,看到作者们做得这么漂亮,我由衷感到欣慰。如果你在J2EE平台下工作,你也就需要了解这些模式。
另外,本书也提出了这样一种观点:当编码开始后,设计并非就结束了。人们在设计时做出的一些决定常常不符合实情。在这种情况下,在构建过程中还需要修正原本的设计,而这种修正必须以一种规范的形式进行。越来越多的人选用"重构"的方法来对现有系统做出更动。本书的作者把我在重构方面的研究应用在一个新领域--也就是J2EE设计的世界之中,这样做还尚属首次。我不仅因为有人在我的研究基础上进行工作而心怀感激,而且,读到他们依据自己的经验,实际描述了如何进行系统重构的转换,我也感到非常喜悦。
说到底,这种经验正是最宝贵的东西。把设计经验固化在书本中,这是最难做的一件事,但是要想让我们的行业进一步发展,这件事又非做不可。本书固化了J2EE开发中的重要经验。没有这本书,就别开发EJB。
Martin Fowler
ThoughtWorks首席科学家