Session Façade 模式 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

  在 J2EE 项目中 DTO 模式常常是与 Session Façade 模式协作使用的。为了执行一个业务逻辑，经常需要访问多个服务器端对象（典型的是实体 Bean ）。这样出现的问题就是多个细粒度的对会话 Bean 和实体 Bean 的调用增加了多个网络调用的开销，而且还有一个问题就是业务逻辑被“下放”的客户端，系统的可维护性降低。

比如我们要修改一个托运协议单，我们首先要找到这个托运协议单，然后对其进行修改，（其中还要请求托运协议单明细，并对托运协议单明细进行修改），然后把修改后的结果发送到服务器。如下图所示：
 

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />
    在一次业务中客户端要与服务器进行四次网络调用。而且实体 Bean 都是具有事务性的，所以每个调用都会在服务器端产生一个独立的事务。而且更加糟糕的是，由于每个对 EntityBean 的调用都是一个独立的事务，那么如果在 updateConsignBillMaster 之后， updateConsignBillDetail 的时候发生了错误，那么就会造成数据的不一致，违反了事务的原子性。

可见这种方式有如下的缺点：

① 高昂的网络调用开销

② 耦合性太高。客户端是根据服务器端的EntityBean的结构写的，如果服务器端发生了改变的话，也必须同时修改客户端。

③ 复用性不好。修改托运协议单的业务逻辑被写到了客户端，如果以后我们要将UI由jsp网页改成applets、或通过Power Builder等开发工具开发前台界面等的时候，这些业务逻辑代码就必须再此重写。

④ 开发人员无法合理分工。在大型项目中，一般都是将表示层（jsp/servlet）、业务层（Session Bean）和持久层（Entity Bean）等由不同的程序员来完成。如果采用我们上边提到的方法的话，表示层开发人员也必须同时理解业务层和持久层的实现方式，这样加大了开发的复杂度和比较高的出错率。

⑤ 无法保证业务的事务性。

我们采用Session Fa ç ade模式解决这个问题：我们将实体Bean包装在会话Bean中，客户端只能访问会话Bean和不能直接访问实体Bean。

采用这种模式后，客户端和服务器的交互将会是这样的：


Session Fa ç ade模式对客户端完全隐藏了存在于服务器端的对象模型，这样也就减少了系统的复杂性，方便开发人员分工，前台表示层开发人员只要调用Session Bean暴露的接口即可，如果业务层发生了变化，只要暴露的接口不变，那么表示层代码就不用做任何改变。而且最重要的是：强制一个业务逻辑在一个网络调用中执行，并且使得所有对Entity Bean的访问都放在同一个事务中，这样就保证了方法调用的事务完整性。

给大家推荐一篇文章
"寂寞鸵鸟"的网上成功之道
[url]http://www.cownew.com/showart.asp?id=54[/url]