From:http://www.uml.org.cn/zjjs/200701295.asp
對DotNet分布式應用搭建的考慮

設計前的考慮和準備工作

　1 對業務需求的理解重要性遠遠勝于對技術架構的理解

2 架構包含技術架構和業務架構

3 沒有萬能和通用的架構，只有符合自身業務需求的架構

4 架構本身的復雜性要截至在架構設計階段

5 擴展性和健壯性是架構設計要考慮的重要內容．

6 第三方工具，開源組件，EnterpriseLib都可借鑒，但絕對不是照單全收

架構設計前需求準備的相關知識

　1 對業務系統中業務的宏觀和整體理解．

2 對DotNet分布式技術的相關知識儲備

3 對Rational統一過程4+1視圖的理解

4 對架構，組件，充用，設計模式，第三方工具組件的學習和借鑒．

業務層面對架構的影響

　1 能否畫出全局的用例視圖,用例驅動體現在哪里？到哪個粒度

2 邏輯視圖是面向對象設計之本

3 邏輯視圖在架構階段要做到哪個層次系統／子系統／模塊／單元

4 什么在決定部署視圖？

5 實施視圖和邏輯視圖的關系，實施視圖作用

技術層面對架構的影響

　1 技術層面重點體現在了實施視圖和部署視圖里面．

2 技術層面重點關注的是非功能性需求．

3 異常／日志／安全／性能／隊列／緩存／離線／

4 系統管理／工作流／公用類／公用組件

5 技術架構的缺陷泄漏對應用系統是致命打擊．

　分布式應用如何構建

　1 現有的分布式技術Remoting // Web Service

2 如何選擇分布式技術：業務需求，性能，開發難易工作量

3 智能客戶端與分布式應用的關系

4 出現前臺展示既有WinUI又有WebUI的時候的統一考慮

5 選擇Remoting+IIS Hosting與Web Service的優缺點對比

6 要盡早出原型對架構進行驗證．

對于系統的異常和日志需求

　1 首先理解清楚業務或系統本身對異常和日志的需求

2 異常和日志一定要配合使用，一些不適合拋給用戶的異常要通過后臺日志記錄下來

3 業務對日志有需求，如登錄日志，操作日志

4 完善的異常日志功能方便后期系統的維護，出現問題后的跟蹤和分析

5 微軟的AppBlock和Log4Net都可以借鑒，但要分析利弊。

　對于系統的安全性的需求和考慮

　1 Remoting的安全性問題，遠程暴露的服務接口是否安全

2 系統的登錄和驗證機制

3 數據傳輸的安全性問題

4 存儲在數據庫中的業務數據的安全性

5 部署到客戶端的程序集的安全性

對于系統緩存的考慮

　1 要好了系統性能大幅度提升，用不好比不用還糟糕

2 對于客戶端緩存和服務器端緩存的選擇問題

3 對于緩存引起的同步和并發問題的考慮和解決

4 擴展性和健壯性是設計時要考慮的重要內容

業務實體的選擇問題

　1 沒有使用O/R Mapping的時候千萬別搞自定義類做實體

2 DataSet (雖對性能有影響，但開發簡潔性和效率提升)

3 類型化和非類型化的優缺點一定要搞的很清楚．

4 再次強調－業務實體和數據庫表間無一一對應關系．

5 與OO的一些區別：對象和對象操作分離開了？利弊在哪里？

轉載于:https://www.cnblogs.com/jhtchina/archive/2007/07/10/813026.html

總結

以上是生活随笔為你收集整理的对DotNet分布式应用搭建的考虑(引用)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。