在过去几年中，enterprise javabeans™（ejb）确实已经开始对 java™ 对象设计产生影响。期间，我们看到的最常使用的 ejb 模式之一是session facade 概念。这是一个让很多开发者都受益匪浅的既强大又非常简单的概念。然而，我也看到，对这一模式的确切含义及其在实践中的应用，人们仍有很多误解。
　　
　　为了把这个问题讲得更明白些，我会在本文中讲述 facade 的一些基本概念以及session facade 模式的工作机制，并探讨该模式衍生出来的一些问题。希望能借此澄清一些误解，并帮助开发者正确使用这种模式。
　　
　　什么是session facade？您又为什么需要它？
　　很多地方都有对session facade 模式的清楚描述，也就是 [sun 2001] 和 [brown 2000]。我不想照抄那里的全部内容，而打算把它的理论在此作个总结：基本的问题是在 ejb 设计中，ejb 客户机（例如，servelet、java 应用程序，等等）不可直接访问 entity bean。
　　
　　之所以如此，有以下几个原因：
　　当依靠 rmi-iiop 进行跨越网络的调用时运行态的性能会受到极大影响。如果客户机请求一个entity bean 去表示如包含两项数据（比方说帐户余额和帐户所有者姓名）的银行帐户，则将需要两个网络调用。当大量属性使网络调用成倍增加时，很快这些开销就会变得非常明显。[monson-haefel] 中所说的批量访问器（bulk accessors）或许是一种解决方案，所谓批量访问器，就是entity bean 上的一些方法，它们创建并返回值对象以表示entity bean 中的数据。它事实上就是 java visualage® 的 copyhelper access beans 采用的解决方案。但是，它有一个令人遗憾的缺陷，就是它假设所有的请求都需要 ejb 中的“所有”数据，结果为用户返回了一些不必要的数据，并导致对更大的值对象进行组织和分解时产生额外开销。
　　
　　更重要的是，如果您允许 ejb 客户机直接访问entity bean，那么就要求客户机了解entity bean 的内部方法，而这已经超出了客户机的应知的范围。例如，操作一个entity bean 需要知道所涉及到的该实体的关系（关联，继承），这样就把业务模型的所有细节不适当地暴露给了客户机。另外，操作多个entity bean 会要求使用客户端事务 ? 这是另一个使事情复杂化的因素，这意味着 ejb 可能要被从客户机设计中除去，而不是添加上去。
　　大多数设计师已经发现为了在 ejb 设计中避免直接访问entity bean 的解决方案都可以在 [gamma] 中描述的 facade 中找到。[gamma] 这样描述 facade 模式：“为子系统中的一套接口提供了一个统一的接口。facade 定义了一个更高层次的接口，使子系统更容易使用。”1在 ejb 中应用这种思想一般意味着您应该创建一个担当 facade 的session ejb，然后把构成子系统的一套entity bean “包装”起来。这样，客户机就和entity bean 实现的细节分离开来了，而且不必自己管理事务管理的细节。
　　
　　但问题是有很多人到此就打住了。然后他们轻松地往下做，开始把entity bean 包装到session bean 中，而不考虑 facade 模式所描述的其它内容以及 ejb 设计中由 facade 模式衍生出来的问题。这很可能是由于把得到的 facade 的“二手”信息都当真，而没去研究原始模式的缘故。如果我们确实花了些时间去理解 facade 衍生的问题，我们将可以看到很多该模式所固有的其它有益的设计可能性。
　　
　　facade 模式的要点
　　[gamma] 中描述了很多我们应该了解的 facade 模式的要点。前面几点可在 facade 模式的“适用性”描述部分找到，它描述了在什么情况下您会需要应用该模式。它们是：“当您想为复杂的子系统提供一个简单接口时……请使用 facade 模式”和“当您想把子系统分层时……请使用 facade 模式。使用 facade 为每一层子系统定义一个入口点。”2
　　
　　从对 facade 模式的讨论中，我们可以提炼出两个观点。第一点是 facade 应该提供子系统的一个抽象视图，而不是简单地把整个子系统本身的 api 直接包装起来。不幸的是，我在实际中多次看到开发者创建的session bean 把entity bean home 和entity bean 对象的全部方法直接包装起来，而不提供任何额外的抽象，这是对该模式最可恶的滥用情况之一。请记住，这种思想是想降低整个系统的复杂性，而不是把复杂性转移到另一个对象上。
　　
　　第二点，也是更微妙的一点，与分层有关。这个观点认为您可以用多重 facade 来隐藏下层子系统的细节。因此，在这里您可以这样设想，session facade 应该在其它 facade 之上，位于最上层，是对底层业务逻辑细节的进一步抽象。这一点很关键。当您看完下面两条（分别出自 [gamma] 中论述 facade 模式的“协作”和“相关模式”部分）叙述后，就会更加清楚这一点：
　　
　　“客户机通过把请求发送给 facade，再由 facade 把请求转发给适当的子系统对象来与子系统通信。”3
　　“facade 只是对通往子系统对象的接口进行抽象以使它们更易于使用；它不定义新功能。”4
　　我把这几点总结如下：facade 不做系统的实际工作；而是委托其他对象轮流做这个工作。由此推理出您必须正确地放置这些对象，以便使该模式能按照您所期望的运行。
　　
　　这一点是本模式的两种流行表达 [sun 2000] 和 [sun 2001] 之间的主要不同之处。第一个版本，即 [sun 2000]，是 j2ee 规划的一部分，它把这种模式称为“session entity facade”。它意在表明“为一堆企业 beans 提供单一的接口”。它描述了这样一种模式，即所有的数据存取都通过entity bean 来完成，session bean 则为这些entity bean 提供接口。现在的问题是 [sun 2000] 不一定非要以 ejb 为中心。它根本不涉及其它对象类型，并且假设系统中只有 ejb 一类对象。根据我的经验，我认为这会导致根本不能在工程间重用的臃肿的session对象，而且，在同一个工程内，当需求有一点不同时就会出现问题。
　　
　　现在，[sun 2001] 则更通用，也没有上述问题的困扰。它简单地把这种模式称为“session facade”。它的解决方案规定您应该“把session bean 当作 facade 来用，以封装参与工作流的业务对象之间的交互操作的复杂性”。它根本不限制您的业务对象应该为 ejb，因此是一个更加灵活的方法。
　　
　　session facade 的重要规则
　　那么我们该如何应用这些关于针对会话的 facade 的规则呢？这对我们的 ejb 设计又意味着什么呢？我在设计session facade 时遵循三条基本原则：
　　
　　它们自己不做实际工作；它们委派其它对象做实际工作。这意味着session facade 中的每个方法都应该很小（异常处理逻辑不计算在内，代码应为五行或更少）。
　　它们提供简单的接口。这意味着 facade 方法的数量应相对较少（每个session bean 中仅有约 24 个）。
　　它们是底层系统的客户端接口。它们应该把特定于子系统的信息封装起来，并且不应该在不必要的情况下公开它。
　　那么它的工作机制呢？您还能代理别的哪些类型的对象呢？这又会给您的设计带来什么好处呢？在我的一篇早期论文和 [brown 2001] 这本书中，我已论述了其中一些问题，在那里可以找到一些详细信息。但，总的来说，在我的多数 ejb 设计中我通常会找到以下四类对象：
　　
　　值对象是包含了客户机所请求的数据的、可序列化的 java bean。它包含entity bean 和其他数据源所包含的数据的一个子集。它是session ejb 方法的返回类型。[ejb 2.0] 和 [sun 2001] 都描述了值对象和值对象的用途。请注意 [fowler 2001] 称其为“数据传输对象”（ data transfer objects ），[brown 1999] 也使用这个名称。我个人觉得数据传输对象是描述性更好的术语，但不幸的是，sun 的术语似乎更通用。
　　对象制造厂 (factory) [brown 1999] [brown 2000] 负责构建值对象。它能完成辨别不同的数据源、创建值对象的实例、填充值对象的实例等等工作。每个 factory 类 都可以从多个数据源中检索数据或更新其中的数据。在您的对象模型中，每个“根”对象都应该有一个 factory 类。（根对象是那些“包含”其它对象的对象。）从某种意义上说，对象 factory 类在 jdbc 或持久的 entity bean 子系统上担当 facade，实现 [gamma] 中提到的分层原则。
　　entity ejb 应该是标准的、企业全局范围内可用的“数据源”。entity bean 不应包含特定于应用程序的域逻辑，也不应限制为只能在单一应用程序内工作。请注意entity bean 是可选的，它不是这种体系结构中必需的部分；factory 可能像 jms 队列或 jdbc 连接那样简单地直接从数据源获取数据。
　　action 对象是session bean 可能调用的唯一对商业业务进行处理的对象。action 对象只处理与简单的创建、读取、更新或删除数据无关的商业流程。和对象 factory 一样，action 对象也充当内层 facade。
　　
　　一个 ejb 对象示例
　　描述类似这样的模式遇到的一个问题是，能够使用这种模式的示例都太大，以至于无法包含在模式自身的描述中。尽管如此，我还是要尝试举出如下示例（它显然很简单）来说明一下这些对象看起来是什么样子。
　　
　　假设我们正在为银行构建一个 atm 系统。这是最老掉牙的 oo 设计问题之一，当然其它很多书籍和论文已经讨论过它，但它确实有足够符合我们要求的有趣特点。通过分析，我们发现了两种 ejb。
　　
　　从 atm 到银行的连接表示为session bean。该 bean 上有一些方法负责处理您通过 atm 可以完成的交易 ? 存款、取款以及帐户间的资金转移。
　　帐户表示为entity bean（我们的示例采用 cmp，但它在我们的示例中实际上并没什么影响）表示。它有返回帐户余额、对帐户进行借贷处理的方法。
　　atm session bean 的远程接口如下：
　　
　　package com.ibm.bankexample.ejbs;
　　
　　import com.ibm.bankexampl