Session Facade 的规则和模式（1）

核心提示：session Facade 的规则和模式（1） 在过去几年中，EnterPRise javaBeans™（EJB）确实已经开始对 Java™ 对象设计产生影响，Session Facade 的规则和模式（1），期间，我们看到的最常使用的 EJB 模式之一是Sessio

　　session Facade 的规则和模式（1）

在过去几年中，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对象，而且，在同一个工程内，当需求有一点不同时就会出现问题。