J2EE核心模式（原书第2版）——Sun公司核心技术丛书

本书讲解使用J2EE核心技术实现企业应用过程中的模式、最佳实践、设计策略以及经过验证的解决方案，涵盖了JSP、servlet、EJB、JMS等技术，其中J2EE模式目录包括21个模式以及大量策略，帮助读者迅速熟练掌握J2EE技术，从而构建出健壮、高效的企业应用。本书是计算机应用开发人员、架构师、技术经理等人员的必备参考书。

Deepak Alur是Sun Java中心的企业Java架构师，具有14年以上的开发经验。他的主要研究兴趣在于利用面向对象技术、模式、Java和J2EE技术完成大型企业应用的架构、设计和实现。 John Crupi是Sun Java中心的杰出工程师和首度Java架构，他有17年以上的分布式对象开发经验，他的主要研究兴趣在于创建可重用的、可扩展的J2EE架构，以及进一步提升J2EE模式的水准。 Dan Malks是Sun Java中心的主任工程师。他有16年以上的开发经验，他的主要研究兴趣在于面向对象技术以及这种技术在企业级的、基于Web Service的项目中的应用。他发表过很多作品，其中既有在行业杂志上发表的论文，也有讨论Jave、J2EE技术及模式的专著。

第一部分 模式和J2EE
第1章 导论
什么是J2EE
什么是模式
历史回顾
模式的定义
模式的分类
J2EE模式目录
演化过程
怎样使用J2EE模式目录
使用模式的益处
模式、框架和重用
小结
第2章 表现层设计考虑和不佳实践
表现层设计考虑
会话管理
控制客户端访问
验证
助手类属性—完整性和一致性
表现层不佳实践
多个视图中都包括控制代码
把表现层的数据结构暴露给业务层
把表现层数据结构暴露给业务领域对象
允许重复提交表单
把敏感资源暴露给客户端的直接访问
假定 会重置Bean属性
创建出“胖控制器”
把视图助手当成scriplet使用
第3章 业务层设计考虑和不佳实践
业务层设计考虑
使用session bean
使用entity bean
缓存EJB的远程引用和句柄
业务层和集成层不佳实践
把对象模型直接映射为entity bean模型
把关系型模型直接映射为entity bean模型
把每个用例映射为一个session bean
通过Getter/Setter方法暴露EJB的所有属性
在客户端中包括服务寻址代码
把entity bean当成只读对象使用
把entity bean当成细粒度对象使用
存储entity-bean的整个从属对象拓扑结构
把EJB相关的异常暴露给非EJB客户端
使用entity bean finder方法返回大型结果集
客户端负责聚合来自业务组件的数据
把EJB用于长时间持续的事务
每次调用无状态session bean都要重建
对话状态
第4章 J2EE重构
表现层的重构
引入控制器
引入同步器令牌
隔离不同逻辑
对业务层隐藏表现细节
去除视图中的转换
对客户端隐藏资源
业务层和集成层的重构
用session bean包装entity bean
引入业务代表
合并session bean
减少entity bean之间的通信
将业务逻辑移至session bean
一般的重构
分离数据访问代码
按层重构系统架构
使用连接池
第二部分 J2EE模式目录
第5章 J2EE模式概览
……

书摘
Grady Booch序
在软件世界中，每个开发机构就像是一个部落，而一个模式就是对部落的某种共同记忆的一种有形表现。模式是对共通问题的共通解决方案，因此，对于某个特定开发机构的文化氛围、某种特定的问题领域来说，命名、确定一个模式，也就是把已经在先前的经验中获得证明的共通解决方案进一步整理成文，设为圭臬。如果你有一套不错的模式语言能随时派上用场，那就像是在开发过程中身旁一直坐着一个专家组：在采用专家们提出的一个模式时，你也就实际获益于他们那些来之不易的经验知识。事实上，那些最好的模式大都不是凭空发明的，而往往是专家们从现有的成功系统中发现、提取而来的。所以，一个成熟的模式中充满了实际有效的内容，不存在空泛不实的内容，同时，它也体现了设计者的智慧和设计思路。
那些深刻的、真正有用的模式大多都是很古老的东西，见到这么一个模式的时候，你往往会说：“嘿，我从前就这么做过。”但是，只有当专家为这个模式命名之后，你才获得了一整套讨论这个问题的语汇；此前，由于缺乏这种语汇，你往往想不到怎样使用这个模式，因此命名有助于我们更好地应用模式。最终，这样一个模式的功效在于，它能让你的系统变得更为简单。
而模式还不仅有助于构建更简单而又实际有效的系统，它们还有助于构建优美的系统。在一种极度缺乏时间的文化氛围中，编写优美的软件常常是不可能的，这是很可悲的事情。因为，我们作为专业人士，本来都应该致力于构建高质量的产品。而通过应用一组恰当的模式，你就有可能为自己的系统注入某种程度的优雅—缺乏模式的帮助，这种优雅往往就无从谈起。
《J2EE核心模式》的作者们提取了一组真正实用的模式。别误解我的意思：J2EE当然是一种重要的软件平台，它能够让开发团队构建出特别强大的软件系统。但是，目前的现实却是，在J2EE提供的抽象层次、服务与开发团队必须构建的最终应用之间，还存在着非常巨大的语义断裂。本书描绘的这些模式，事实上正是人们一次又一次用来填补这种断裂的共同解决方案。应用这些模式，也就是采用了一条最主要的避免软件风险的措施：只要编写更少代码就能获得相同的效果。你也不必再重新自己动手寻找解决方案，这些模式已经在很多现存系统的应用中得到了验证，所以只需应用它们就是了。
作者们不仅完成了一组模式的命名，还利用UML确定了模式的语义，使它们更容易为人理解。并且，他们也介绍了应该如何应用这些模式、如何重构你的系统以便从模式中获益。再说一遍，拥有本书就像一个专家组坐在你旁边一样。

Martin Fowler序
在1998年末，我所在的ThoughtWorks公司就开始使用J2EE了。在那个时候，我们发现了很多很酷（虽然有点儿不成熟）的技术，但是很少有人能说明怎样才能恰当地应用这些技术。也许是因为我们具备在其他OO服务器环境下编程的大量经验，所以我们自己能够应付这些问题。但是我们也见到很多客户费尽了周折—并不是因为技术本身的问题，而是因为不知道怎样才能恰当地应用这些技术。
使用模式，能够固化设计经验—也就是说，模式有助于将经常重现的问题的实际解决方案进行归类、编目。多年以来，对于模式的这种用途，我一直都是个由衷的爱好者。最近的几年里，业界的很多先驱者都在使用J2EE，都在寻找构成一个有效的J2EE解决方案的核心模式。本书对这些模式进行了出色的汇集，其中揭示的很多技术都是我们自己通过多次尝试、多次错误才获得的。
这也就是本书的重要之处。对API倒背如流是一回事；知道如何设计优秀的软件则是另一回事。本书确实致力于固化这一类设计知识，这也是我见到的第一本这么做的书，看到作者们做得这么漂亮，我由衷感到欣慰。如果你在J2EE平台下工作，你也就需要了解这些模式。
另外，本书也提出了这样一种观点：当编码开始后，设计并非就结束了。人们在设计时做出的一些决定常常不符合实情。在这种情况下，在构建过程中还需要修正原本的设计，而这种修正必须以一种规范的形式进行。越来越多的人选用“重构”的方法来对现有系统做出更动。本书的作者把我在重构方面的研究应用在一个新领域—也就是J2EE设计的世界之中，这样做还尚属首次。我不仅因为有人在我的研究基础上进行工作而心怀感激，而且，读到他们依据自己的经验，实际描述了如何进行系统重构的转换，我也感到非常喜悦。
说到底，这种经验正是最宝贵的东西。把设计经验固化在书本中，这是最难做的一件事，但是要想让我们的行业进一步发展，这件事又非做不可。本书固化了J2EE开发中的重要经验。没有这本书，就别开发EJB。