.NET 分布式架構(gòu)開發(fā)實戰(zhàn)之二 草稿設計
可能在項目敲定那天就已經(jīng)清楚是自己設計數(shù)據(jù)庫還是從其他地方獲取數(shù)據(jù)。但是一個通用的一個架構(gòu)的就要能夠為其他的數(shù)據(jù)源預留接口。
這里,可能就有了一點”過度設計”的味道了,起初在項目A中所使用的架構(gòu)沒有考慮其他數(shù)據(jù)源的問題,但是如果在項目B中出現(xiàn)了,怎么辦?那么架構(gòu)就要演化,改進來適應這種情況。
之前也提過,沒有必要一上來就設計強大的就架構(gòu),而是在項目中改進,演化。開始時候沒有考慮到,以后慢慢的加嘛。(比較的糾結(jié))。
上面只是緊緊的從數(shù)據(jù)層DAL的角度進行了思考,DAL最終還是為業(yè)務層BLL提供數(shù)據(jù)的,所以就考慮DAL以何種方式來被BLL調(diào)用,鑒于之前的一些考慮,可以得出一點:不讓BLL直到DAL的實現(xiàn)細節(jié),所以接口似乎是個不錯的解決辦法,Provider的模式也似乎可以排上用場。
于是,Richard就決定在DAL和BLL之前加上接口層來解耦。
3. 第二個數(shù)據(jù)層草圖的提出
這個圖和之前的第一個圖基本上是一樣的,只是做了一修改,而且加上了之前談論中涉及的一些問題。
因為隨著思考的深入,逐漸的發(fā)覺:數(shù)據(jù)源的來源可以很多—數(shù)據(jù)庫,普通文本,XML等等。不同的數(shù)據(jù)源提供不同的Provider,其實從其他的服務接口獲取數(shù)據(jù)也是一種來源,上面的圖之所以單獨的把Service Agent分出,主要是因為比較特殊。
而且圖中的那些基本功能:Log, Exception等,是到處都用到的。
此時Richard也在頭腦中閃現(xiàn)了一些要處理的,可以出現(xiàn)的異常:
1.Data Source is not exits:數(shù)據(jù)源不存在,因為這個問題很常見,比如在項目運行過程中,數(shù)據(jù)庫斷了,或者遠程的服務無法訪問,等等基本都屬于這個問題的。所以這個異?隙ㄊ且幚淼摹
2. Time out:超時。這個異常很常見,獲取的數(shù)據(jù)過大,或者遠程數(shù)據(jù)源連接超時,等,都可以引發(fā)一些問題。
3. 如果數(shù)據(jù)源是其他服務接口提供數(shù)據(jù),那么在數(shù)據(jù)獲取時,可能要轉(zhuǎn)換數(shù)據(jù)格式,如果格式出錯,。或者發(fā)送的數(shù)據(jù)不符合一些規(guī)則,這個異常一定要處理,因為這些數(shù)據(jù)可能涉及到安全的問題了:是數(shù)據(jù)真的不正確,還是被篡改了。
程序就必須對這些異常進行處理:是把原生的異常拋出,然后有業(yè)務層決定如果處理;還是決定把異常包裝稱為另外的一個異常,再拋出;還是最后干脆再DAL就執(zhí)行自己處理,然后給業(yè)務層一個友好的提示,等等。如果數(shù)據(jù)源是遠程的服務,那么如果服務斷了,在異常過程中,采用什么樣的策略:簡單的處理,如拋出異常,記錄日志,還是做一些恢復性的操作,如嘗試重新連接,等。
之前第一張圖中,在DAL上定義一個接口,用來接耦,但是在第二張圖有做了一些修改--把DAL做為服務提供出去。之所以做了這個修改,因為在開始思考的時候,只是認為底層設計的DAL只是給BLL使用。可以發(fā)覺到一點:在DAL中,數(shù)據(jù)可以從遠程的服務中獲取,那么可能我們這里的DAL也可以作為服務給其他的人設計的DAL使用,也就是說,我們的這里的DAL成了遠程服務的數(shù)據(jù)源。所以做了上面的修改。但是這個思考到還會改進,因為這里面問題(讀者朋友可以先自己思考是什么問題)。
今天就寫到這里了,謝謝各位!
下篇講述: .NET 分布式架構(gòu)開發(fā)實戰(zhàn)之三 數(shù)據(jù)訪問深入一點的思考
版權(quán)為小洋和博客園所有,轉(zhuǎn)載請標明出處給作者。
http://www.cnblogs.com/yanyangtian
轉(zhuǎn)載:http://www.cnblogs.com/yanyangtian/archive/2010/05/24/1742432.html
本文鏈接:http://m.95time.cn/tech/program/2010/7752.asp
出處:博客園
責任編輯:bluehearts
上一頁 .NET 分布式架構(gòu)開發(fā)實戰(zhàn)(二) [1] 下一頁
◎進入論壇網(wǎng)絡編程版塊參加討論
|