已經(jīng)好多天沒(méi)有寫(xiě)blog了，原因是從南京轉(zhuǎn)到北京工作，還不太習(xí)慣，工作也很忙，上班時(shí)間不可以登陸blogjava這樣的網(wǎng)站，下班后又要會(huì)會(huì)多年沒(méi)見(jiàn)的一些老朋友（或者從來(lái)就沒(méi)有見(jiàn)過(guò)的朋友），回到酒店又沒(méi)有上網(wǎng)的條件——“上帝啊！上地大廈居然不能上寬帶！”

隨著這兩天工作的深入，我們項(xiàng)目組遇到了一些問(wèn)題，我將其中一個(gè)我認(rèn)為很有價(jià)值又很有爭(zhēng)議的問(wèn)題抽象出來(lái)寫(xiě)在下面，供大家討論。

項(xiàng)目組已經(jīng)決定了要在后臺(tái)系統(tǒng)的組織上采用Facade＋懶加載的形式。這個(gè)方案意味著要為Facade提供多個(gè)多級(jí)多層次的get方法，以便上層業(yè)務(wù)能根據(jù)自己的需要直接獲得關(guān)心的組件或關(guān)心的對(duì)象。并且如果在整個(gè)運(yùn)氣期都沒(méi)有一個(gè)對(duì)象去get某個(gè)對(duì)象的話，后者很可能不被裝載，其它的對(duì)象和組件也只在需要時(shí)載入并運(yùn)行。這個(gè)方案基本通過(guò)。現(xiàn)在的問(wèn)題是有人提出少數(shù)組件應(yīng)該具有伸縮性，所以應(yīng)該采用容器＋Service的形式實(shí)現(xiàn)，事實(shí)上Facade太死板不夠靈活，服務(wù)模式有很多能力是Facade模式所沒(méi)有的，所以應(yīng)該加入。反對(duì)者（包括作者）認(rèn)為既然已經(jīng)有了一種解決方案，為什么還要另一種方案的參與呢。爭(zhēng)論使得項(xiàng)目組的所有成員在很長(zhǎng)一段時(shí)間里（約一個(gè)多小時(shí)）都沒(méi)能做其它事情。現(xiàn)在我把這個(gè)難題交給blogjava的朋友們，希望回帖討論，謝謝。

做平臺(tái)的泡泡