ID #81644

Session Facade 的规则和模式


  在过去几年中,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 实现的细节分离开来了,而且不必自己治理事务治理的细节。

2011-09-28 19:03
阅读:
I'm VC , Just U know Y
本站部分文章来源于互联网,版权归原作者所有。

延伸阅读:

struts1与struts2的区别

用Java编写计算器的几种常见的做法

九大因素让Java EE 6成为你的省钱法宝

java的一些网址

Java时间更新周期测试