上一篇我們聊了如何用Java語言構(gòu)建一個應用服務器。今天我們聊一下，如何更優(yōu)雅的生成一個動態(tài)的信息頁面。

在C/S客戶端年代，事件驅(qū)動型的開發(fā)模式給大家留下了太深的印象了?？丶献А⑺娂此?、編寫事件代碼，每個使用過VB或者PB的人大概都會有爽的感覺。

在B/S的時代，美好再也沒有了。我們必須得明確的認識到，哪些是在瀏覽器運行的，哪些得要在服務端運行，而且這之間需要經(jīng)過Http的網(wǎng)絡傳輸，是有性能代價的。

但是追求美好的腳步從來沒有停止過。從最早的Asp.Net體系開始，微軟為大家構(gòu)建了一個橫跨瀏覽器和服務端的組件體系，幾乎讓我們感覺不到跟C/S軟件之間的開發(fā)區(qū)別?？上④浀拇a對我們來說是個黑盒，具體實現(xiàn)不得而知，更可怕的是，當我們想擴展一些自己的實現(xiàn)或優(yōu)化的時候，只能說不太容易。自由和封閉從一開始就是個矛盾的選擇，猶如安卓和蘋果。

開源體系其實也有類似的嘗試，比如JavaEE的JSF框架。我們先不去研究他的具體實現(xiàn)，先想一下假設我們自己來，我們怎么去設計。

首先，在Html端得有一套組件體系，我們需要把每個UI組件抽象出一個Root類，這個UI組件得能自己渲染Html代碼，同時能接受界面點擊等事件。UI組件還得有一個組合類，可以允許包含其他子組件。每個組件還得允許他的子類可以實現(xiàn)自己的渲染和事件處理邏輯。

然后，我們在服務器端，也得實現(xiàn)一套對應的UI組件體系。當Html被請求后，服務端首先找到對應的組件描述文件，然后解析這個文件，生成服務器端UI樹，并且渲染出Html端的組件樹。Html代碼最終被返回給瀏覽器，同時，在服務器端也建立了一個和瀏覽器端一一對應的組件樹。

當瀏覽器端有事件產(chǎn)生的時候，事件發(fā)生的組件ID以及事件信息會被發(fā)送到服務器端，服務器端通過請求URL找到對應的組件樹，以及發(fā)生事件的組件，調(diào)用這個組件的事件代碼。組件事件代碼中，會對組件樹進行一系列邏輯操作，這些操作要被翻譯成瀏覽器能理解的命令串。具體來說就是哪個組件ID，進行什么操作之類的。這些命令串被返回給瀏覽器端，最終解析執(zhí)行，影響頁面的展示。

整個流程說起來簡單，但是做起來確實很麻煩。有興趣的朋友可以去看一下JSF的幾個開源實現(xiàn)。這里推薦大家去看一下ZK框架，這是我見過最完美的實現(xiàn)，當然，他并沒有完全遵循JSF的標準。

事情就是這樣，沒有絕對的對與錯。ZK雖然已經(jīng)很完美，但是對他做一些定制擴展，還是不容易的。

我們回到這個事情的本身來看，前端和后端天然要有網(wǎng)絡的傳輸，除非網(wǎng)速快到大家完全無感知，如果用戶體驗要求很高，我們總要做一些特殊的處理。

另外，前端和后端的工作確實各有側(cè)重，前端更注重用戶的體驗，后端更關(guān)注性能、可用性、數(shù)據(jù)一致和安全等等。職業(yè)的分工是合理的，能夠提升整體的效率和質(zhì)量。

最后，回到業(yè)務本身，我們還是要根據(jù)自己的業(yè)務特點進行抉擇。如果是后臺業(yè)務系統(tǒng)，要求的是數(shù)據(jù)準確、功能好用，界面反而是次要的，那就可以采用這種事件驅(qū)動的框架。如果是服務大眾的產(chǎn)品，用戶體驗至上，那還是建議前后端的分離，各自優(yōu)化。

總結(jié)一下，BS架構(gòu)設計也曾想追求事件驅(qū)動的開發(fā)模式，但是，有得就有失，我們需要自己去選擇。