canonical

? 在采用AJAX技術(shù)的應(yīng)用中, 常見的是兩種架構(gòu)設(shè)計(jì), 一種是采用RPC(Remote Procedure Call)方案, 后臺(tái)應(yīng)用直接將java對(duì)象包裝為service接口, 在js對(duì)外暴露(java對(duì)象完全不知道web層), 在js中通過類似函數(shù)調(diào)用的方式訪問后臺(tái)服務(wù).而另外一種方案是在后臺(tái)維持一個(gè)前臺(tái)DOM節(jié)點(diǎn)的映象,觸發(fā)前臺(tái)事件之后, 前臺(tái)引擎自動(dòng)截獲該事件, 并翻譯為對(duì)后臺(tái)事件監(jiān)聽器的調(diào)用, 將請(qǐng)求提交到后臺(tái), 后臺(tái)程序處理請(qǐng)求之后更新后臺(tái)DOM節(jié)點(diǎn), 然后將頁面變更部分傳回前臺(tái)頁面. 這兩種方案一種是傾向于在js中提供自我封閉的程序模型(對(duì)遠(yuǎn)程服務(wù)的調(diào)用體現(xiàn)為對(duì)一個(gè)js函數(shù)的調(diào)用), 一種是傾向于在后臺(tái)提供封閉的程序模型(對(duì)前臺(tái)頁面的更新體現(xiàn)為對(duì)一個(gè)后臺(tái)java對(duì)象的屬性和結(jié)構(gòu)的改變). 這兩種方案的共同之處在于它們都試圖在一定程度上屏蔽前后臺(tái)程序的交互細(xì)節(jié), 而提供一種統(tǒng)一的程序模型.
? 但是我們需要記住軟件設(shè)計(jì)的第一要義在于系統(tǒng)的分解, 而Browser和Server之間客觀存在的http信道是天然存在的一種分界線. 任何強(qiáng)迫我們忘記B/S之間的界限的技術(shù)都是需要謹(jǐn)慎對(duì)待的. 例如控制后臺(tái)對(duì)象的權(quán)限問題, 很多RPC方案限制了應(yīng)用程序?qū)τ趙eb接入層的直接接觸, 而只能通過AOP(Aspect Oriented Programming)技術(shù)來動(dòng)態(tài)織入權(quán)限控制代碼. 在實(shí)際使用中, 這種方式往往因?yàn)閟ervice接口函數(shù)的多樣化而造成配置上的繁瑣.? 而在我們的體系架構(gòu)中, 系統(tǒng)邊界劃分在web訪問層上(而不是java service層), 借助于web訪問協(xié)議自身的一致性和透明性, 我們只需要如下實(shí)現(xiàn)
?? Object invokeWebEvent(){??? ???
???? return new ActionMethodInvocation(getWebObject(), getObjectEvent(), getInterceptors()).proceed();
?? }
就為所有WebObject加入interceptor堆棧, 完全不需要AOP的動(dòng)態(tài)織入技術(shù).
? 在witrix平臺(tái)的設(shè)計(jì)中, 因?yàn)榇罅坎捎胮ull方案, 我們對(duì)于前后臺(tái)交互方式采取的是完全開放的態(tài)度, 前后臺(tái)的交互接口完全定義在web訪問層上(即前臺(tái)程序直接訪問一個(gè)url獲取數(shù)據(jù)), 盡量避免將系統(tǒng)架構(gòu)的限制引入到應(yīng)用程序設(shè)計(jì)中來. 確實(shí), Browser和Server之間的原始交互方式是受限制的, 狹窄的, 但是從系統(tǒng)設(shè)計(jì)的角度上說, 這正是異構(gòu)系統(tǒng)集成和進(jìn)行系統(tǒng)核心控制的最好場(chǎng)所, 任何試圖獨(dú)占該連接信道并在層層封裝之后提供更加豐富的訪問語義的努力在我看來都是可疑的.
?