RAD外層框架應(yīng)該具備的內(nèi)容

　　現(xiàn)在大家都熱衷分層，一個(gè)分布式系統(tǒng)是應(yīng)該適當(dāng)分層，但要適度。如果分層太多把系統(tǒng)搞得太復(fù)雜反而是適得其反，因此我一直的一個(gè)觀點(diǎn)是架構(gòu)本身可以具備復(fù)雜性，但復(fù)雜性是內(nèi)聚的，不應(yīng)該暴露給最終的開發(fā)人員和使用者。類似于分層，搞得一個(gè)簡(jiǎn)單的功能都要涉及到5,6個(gè)甚至更多的類需要和修改，顯然對(duì)開發(fā)效率是有影響的，而且分層太多反而是系統(tǒng)不穩(wěn)定，出了異常跟蹤起來也困難。
 
接著我們考慮RAD底層框架需要考慮的一些內(nèi)容:
 
1.數(shù)據(jù)持久層選擇：這里需要引入相關(guān)的O/R Mapping組件�，F(xiàn)在用過的感覺XPO比較好，但是商業(yè)化的軟件。如果使用NHibernate,Castle或Gentle，則還需要處理大量的配置信息，而這些配置信息到了RAD平臺(tái)下都需要系統(tǒng)自動(dòng)的去處理和生成。其實(shí)不管用哪種組件，對(duì)于數(shù)據(jù)集的綁定上面始終是無法提供很好的支持的。而使用DataSet或Typed DataSet則基本無此問題，但需要自己來實(shí)現(xiàn)一些O/R Mapping的功能。
 
2.異常日志的處理：這應(yīng)該是系統(tǒng)最基本的一個(gè)功能，在這里不推薦使用App Block或其它開源組件了。這塊可以根據(jù)RAD平臺(tái)的自身業(yè)務(wù)需要自己寫代碼來實(shí)現(xiàn)。主要是要明確具體的業(yè)務(wù)需求，如方面問題的跟蹤和Debug，異常能夠記錄下來，用戶相關(guān)操作能夠記錄下來，發(fā)生異常時(shí)候給用戶拋出友好提示但相關(guān)實(shí)際的錯(cuò)誤堆棧又能夠記錄。這塊的實(shí)現(xiàn)切記是簡(jiǎn)單好用，搞得太復(fù)雜了反而不好用，而且往往需要大量的配置信息。mda.com
 
3.分布式的安全性問題：分布式的安全性主要需要考慮暴露的遠(yuǎn)程服務(wù)接口的安全性，另外就是數(shù)據(jù)傳輸過程中的安全性。基本就是這兩個(gè)大問題，對(duì)于Web Service可以采用增加Soap Header來實(shí)現(xiàn)驗(yàn)證或采用WSE。對(duì)于Remoting安全性可以考慮增加自定義Sink的方式，以Addin插件的方式加入，這樣可配置性和擴(kuò)展性都很強(qiáng)，這塊在Sharp Develop IDE和Indigo中有很多可借鑒內(nèi)容。
 
4.分布式的實(shí)現(xiàn)問題：用戶可以選擇具體分布式的實(shí)現(xiàn)方式，系統(tǒng)應(yīng)該通過用戶選擇的方式自動(dòng)生成相關(guān)的服務(wù)接口類和服務(wù)代理類。所以這里對(duì)于Remoting+IIS來實(shí)現(xiàn)分布式是最簡(jiǎn)單的一種方式，只需要配置客戶端和服務(wù)器端的兩個(gè)Xml文件即可以實(shí)現(xiàn)分布式。因此這里的分布式實(shí)現(xiàn)將轉(zhuǎn)換為一個(gè)部署問題，用戶在RAD建模完成后通過一個(gè)發(fā)布功能即可以將系統(tǒng)發(fā)布為一個(gè)分布式的系統(tǒng)。