一直在思考分布式系統設計的問題，業務對象原封不動的情況下部署在用戶端和伺服器端，可以根據配置檔案選擇是連接配接伺服器還是連接配接本地的資料庫，這個問題讓我絞盡腦汁，我總是設想的用戶端與伺服器端通信的方式是最低端的Socket。花了兩個晚上研究CSLA.NET架構關于資料門戶這塊代碼，才發現問題的關鍵所在：用戶端與伺服器端通信不能采用最低端的Socket，而要用高端的WebService、.NET Remoting或者是自己定義一種協定等，隻要它們支援用戶端直接根據伺服器端的服務URL、類名、方法名和方法參數四個資訊就可以調用伺服器對應的類和方法就行。
說明：本文中所表達的思想與CSLA.NET有很大差別，不要看了本文就以為是CSLA.NET的設計思想，也不要以為本文錯誤的解釋了CSLA.NET，這不是一篇介紹CSLA.NET的文章，但純思想上它們是相同的。
分布式系統的部署
平常我們都說三層架構，我認為它是一個廣義的模型，更多層的設計可以合并相鄰幾層的方式最終回歸到三層這個寬泛的概念上來，我的意思是：這些都隻是概念，忘記這些概念去實際分析設計會離這些概念更近一些。
接下來我要把三層變的更簡單點，兩層，資料通路層合并到業務層，統稱為業務層，因為我們面對的問題不是分層的問題，而是分布式系統中各層應該怎麼部署的問題。在CSLA.NET書中也說到業務層和資料通路層放到同一台機器上可以提高性能和容錯性。是以他們倆的合并不影響分布式系統的部署。
不過要解釋的是資料庫系統（CSLA.NET中說的資料存儲和管理層）并沒有考慮到三層中來，也就是它不包含在資料通路層中，如果把它算進來，那麼它是在資料通路層之下單獨存在的。
綜上，在分布式系統部署角度考慮的分層實際是三層：界面層、業務層（包含資料通路層的業務層）、資料存儲層。
下面舉例說明可能的部署情景，帶陰影的框框表示一台機器，虛線框表示根據使用場合可有可無，虛橫線表示從此處劃開單獨出伺服器。在B/S應用中，Web浏覽器為用戶端，其他全部為伺服器。在C/S應用中，處在最上層的界面層+業務層為用戶端，其他為伺服器。
非分布式系統的部署
單機版
兩三台機器
分布式系統的部署
分布式的Web系統
分布式的C/S系統
有幾點要說明：
1． 用戶端上的驗證等業務邏輯是不可信的，是以任何一種部署都需要伺服器端包含業務層；
2． 為了開發、維護和部署中的高度可伸縮性，圖中的各業務層所包含的代碼都是一模一樣的；
3． 因為第2點，是以我遇到了業務層的同一個操作是與其他機器上的業務層通信還是通路資料庫這個難題。
解決業務層的資料通路問題
這個問題是關鍵問題，也就是上面幾點說明中的第3個問題，為了解決這個問題我們引入資料門戶的概念。
下面以WebService為例說明：界面層通路本機的業務對象的增删改查中的“查”方法時，跳過資料庫的查詢操作，通路另一台機器中的同一個業務對象類的“查”方法。
以上是向另一台機器發送請求，該請求并不直接調用另一台機器上的業務對象類的“查”方法，而是将要調用的業務對象和方法參數資訊轉為一個“二進制包”，作為參數去調用另一台機器上通用的“查”方法，另一台機器上的“查”方法再解開這個包，然後去調用解開的包中所表示的業務對象類型，下面的靜态圖是另一台機器接受到請求後的工作。