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。
采用这种模式后，客户端和服务器的交互将会是这样的：
|