Session Fa?ade
模式
?
在
J2EE
項(xiàng)目中
DTO
模式常常是與
Session Fa?ade
模式協(xié)作使用的。為了執(zhí)行一個(gè)業(yè)務(wù)邏輯，經(jīng)常需要訪問多個(gè)服務(wù)器端對象（典型的是實(shí)體
Bean
）。這樣出現(xiàn)的問題就是多個(gè)細(xì)粒度的對會話
Bean
和實(shí)體
Bean
的調(diào)用增加了多個(gè)網(wǎng)絡(luò)調(diào)用的開銷，而且還有一個(gè)問題就是業(yè)務(wù)邏輯被“下放”的客戶端，系統(tǒng)的可維護(hù)性降低。
比如我們要修改一個(gè)托運(yùn)協(xié)議單，我們首先要找到這個(gè)托運(yùn)協(xié)議單，然后對其進(jìn)行修改，（其中還要請求托運(yùn)協(xié)議單明細(xì)，并對托運(yùn)協(xié)議單明細(xì)進(jìn)行修改），然后把修改后的結(jié)果發(fā)送到服務(wù)器。如下圖所示：
???
在一次業(yè)務(wù)中客戶端要與服務(wù)器進(jìn)行四次網(wǎng)絡(luò)調(diào)用。而且實(shí)體
Bean
都是具有事務(wù)性的，所以每個(gè)調(diào)用都會在服務(wù)器端產(chǎn)生一個(gè)獨(dú)立的事務(wù)。而且更加糟糕的是，由于每個(gè)對
EntityBean
的調(diào)用都是一個(gè)獨(dú)立的事務(wù)，那么如果在
updateConsignBillMaster
之后，
updateConsignBillDetail
的時(shí)候發(fā)生了錯(cuò)誤，那么就會造成數(shù)據(jù)的不一致，違反了事務(wù)的原子性。
可見這種方式有如下的缺點(diǎn)：
①
高昂的網(wǎng)絡(luò)調(diào)用開銷
②
耦合性太高。客戶端是根據(jù)服務(wù)器端的EntityBean的結(jié)構(gòu)寫的，如果服務(wù)器端發(fā)生了改變的話，也必須同時(shí)修改客戶端。
③
復(fù)用性不好。修改托運(yùn)協(xié)議單的業(yè)務(wù)邏輯被寫到了客戶端，如果以后我們要將UI由jsp網(wǎng)頁改成applets、或通過Power Builder等開發(fā)工具開發(fā)前臺界面等的時(shí)候，這些業(yè)務(wù)邏輯代碼就必須再此重寫。
④
開發(fā)人員無法合理分工。在大型項(xiàng)目中，一般都是將表示層（jsp/servlet）、業(yè)務(wù)層（Session Bean）和持久層（Entity Bean）等由不同的程序員來完成。如果采用我們上邊提到的方法的話，表示層開發(fā)人員也必須同時(shí)理解業(yè)務(wù)層和持久層的實(shí)現(xiàn)方式，這樣加大了開發(fā)的復(fù)雜度和比較高的出錯(cuò)率。
⑤
無法保證業(yè)務(wù)的事務(wù)性。
我們采用Session Fa
?
ade模式解決這個(gè)問題：我們將實(shí)體Bean包裝在會話Bean中，客戶端只能訪問會話Bean和不能直接訪問實(shí)體Bean。
采用這種模式后，客戶端和服務(wù)器的交互將會是這樣的：
Session Fa
?
ade模式對客戶端完全隱藏了存在于服務(wù)器端的對象模型，這樣也就減少了系統(tǒng)的復(fù)雜性，方便開發(fā)人員分工，前臺表示層開發(fā)人員只要調(diào)用Session Bean暴露的接口即可，如果業(yè)務(wù)層發(fā)生了變化，只要暴露的接口不變，那么表示層代碼就不用做任何改變。而且最重要的是：強(qiáng)制一個(gè)業(yè)務(wù)邏輯在一個(gè)網(wǎng)絡(luò)調(diào)用中執(zhí)行，并且使得所有對Entity Bean的訪問都放在同一個(gè)事務(wù)中，這樣就保證了方法調(diào)用的事務(wù)完整性。
給大家推薦一篇文章
"寂寞鴕鳥"的網(wǎng)上成功之道
http://www.cownew.com/showart.asp?id=54