Session Fa?ade 模式

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

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

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

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

① 高昂的网络调用开销

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

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

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

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

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

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