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

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