聽說讀寫

某個項目需要使用很多內(nèi)部其他Team的DLL 和第三方的DLL (大概百來個吧......這是什么鬼啊...可怕的歷史,又不能改 這些dll都上生產(chǎn)環(huán)境了)

如果直接用dll引用之后調(diào)用  會有很多很多的問題

　　1.程序的質(zhì)量會下降到 這百來個dll中質(zhì)量最差的一個 (萬一某些人在代碼里面寫什么lock(string) 啊什么的....死啦死啦的)

　　2.很多dll需要特殊的配置 把這些東西都放在web.config就準(zhǔn)備等死吧...也不知道哪些是哪些,維護很容易死人

　　3.有些dll也許內(nèi)部做了什么cache啊 或者開了什么socket端口啊 這種東西.. (有個組件TMD的內(nèi)部緩沖了1G的數(shù)據(jù),要死人啊,堅決關(guān)掉他)

　　4.要避免不同組件之間的沖突,例如一個dll的配置影響到其他dll的配置

最終要實現(xiàn)的效果是

 　　配置文件隔離

　　不同組的DLL之間隔離,不要讓代碼互相影響

想為他們做一下隔離,想了以下的方案

　　1.服務(wù)器隔離, 把若干個dll分為一組,部署為webservice(或socket之類的)到其他服務(wù)器上 , 通過這種方式調(diào)用相互之間的影響最小

　　2.進程隔離, 把若干個dll分為一組,弄一個HOST 在console或者window service 上. 通過named pipe, message之類的方式通信

　　3.Application Domian隔離...這個就沒啥好說了,開發(fā)比較簡單

1和2的開發(fā)成本太高了 而且以后debug也是一個大問題......

3的問題是

　　a.現(xiàn)在的第三方組件的類很多沒有標(biāo)記為Serializable 也不繼承MarshalByRefObject, 輸入輸出參數(shù)也沒有標(biāo)記為Serializable,

　　b.需要額外的編碼量,相對于直接引用來說, 增加調(diào)試難度

　　c.性能問題 大數(shù)據(jù)量的序列化反序列化造成性能損失(performance hurt)

目前看起來還是比較靠譜, 不過還需要做一下程序原型設(shè)計...

　　1.看看究竟能不能走的通

　　2.如何減少編碼量

　　3.性能問題影響大么?怎么解決