分布開發分布式設計的原則

原則1：保守分布

這項原則基於乙個事實：呼叫不同程序上物件的方法要比呼叫程序內物件的方法慢數百倍；將物件移動到網路中的另一台計算機上，這種方法呼叫又會慢數十倍。

拿資料層舉例，在決定使用資料庫時，一般需要決定分布資料來源邏輯。然而，決定分布表示邏輯會更複雜一些。首先，除非所有應用使用者都使用公共的終端，否則表示層的某些部分就必須頒布到每個使用者機上。

但問題是分布到什麼程度。當然，近來的趨勢是在伺服器上執行大部分邏輯，而將簡單的html傳送到客戶端web瀏覽器。實際上，這正是遵守了保守分布的原則。

然而，它也需要每個使用者互動都遍歷伺服器，從而這些使用者互動才能產生正確的響應。

在web迅速發展之前，普遍的情況是在每個客戶機上執行整個表示邏輯，這樣可以與使用者更快地互動，因為它最小化了伺服器上的遍歷，但它也需要更新使用者介面並被部署到整個使用者群。最後，選擇使用哪乙個客戶機基本上與分布設計原則無關，但都與期望的使用者經驗和部署問題有關。

資料邏輯幾乎總是在乙個獨立的計算機上執行，表示層通常也是如此。現在只剩下業務邏輯，它是整個問題組中最複雜的部分。業務層有時被部署到每個使用者，而其他時候則被儲存到伺服器上。

在許多情況下，業務層被分解兩個或更多個元件，與使用者接**互相關的元件被部署到客戶機處，而與資料訪問相關的元件則被儲存到伺服器上。這就遵守了本地化相關內容的原則。

可以看到，您有許多分布選項。分布的時間、原因以及如何分布等受到很多因素的影響，其中的許多因素又互相競爭。

原則2：本地化相關內容

如果決定或被迫分布全部或部分業務邏輯層，那麼應當保證經常互動的元件被放置在一起。換句話說，您應當本地化相關內容。

舉例：在做電子商務中的購物車時，客戶元件、商品元件、購物車元件之間就需要多次互動。每一次互動都會帶來跨網路方法呼叫的系統開銷。因此，這種跨網路的行為會抵消掉並行處理帶來的好處。

再考慮到幾千使用者會同時使用，可想其後果是破壞性的。

應用示例：

可以將應用程式駐留到多台web伺服器，進口處由負載平衡器來分配，出口都進資料庫。該設定稱為web場。

原則3：使用chunky介面，而不是chatty介面

chunky是粗粒度，chatty是細粒度。

粗粒度指方法中傳的值用屬性表示，細粒度指傳的值用物件表示。

在細粒度介面中，被傳的方法物件，如果位於客戶機程序中，則這個示例不會產生任何問題。可是，設想一下每個屬性和方法呼叫跨越大西洋進行遍歷，這將會產生嚴重的效能問題。

原則4：優先選用無狀態物件，而不是有狀態物件

無狀態物件是能夠在方法呼叫之間被安全建立和銷毀的物件.如果應用程式選擇銷毀它,這個動作也不會影響到其他使用者.這個特性不是輕易就能實現的,您必須對類進行特殊實現,這樣類才不會依賴於公共方法呼叫之後例項字段是否繼續存在.

因為對例項字段沒有依賴關係,所以無狀態物件傾向於使用chunky介面.

通過使用智慧型快取、會話管理和負載均衡的方法，可以避免或者最小化使用有狀態物件所帶來的問題。這就是使用無狀態物件的原因，但不是必須使用。這裡需要再次說明，這個原則只能應用於為在其他機器中執行的**所提供的物件。

原則5：介面程式設計，而不是具體實現的程式設計

減少頻繁的且時常出問題的部署

分布式程式設計的定義：

分布式程式設計的特點是讓幾個物理上獨立的元件作為乙個單獨的系統協同工作。

物理上獨立的元件可能指之個cpu，或者更普遍的是指網路中的多台計算機。

分布式程式設計的作用：

如果一台計算機能夠在5秒鐘內完成的任務，那麼5臺計算機以並行的方式一起工作時就能在1秒鐘內冤魂成一項任務。

應用程式的分層：

大多數業務應用程式是由3個主要邏輯部分構成：表示邏輯、業務邏輯和資料邏輯。

設計任務商業應用程式的首要之處是將應用程式的各個部分邏輯劃分為不同的層次。換句話說，不能將業務邏輯**與表示邏輯**混在一起。然而，不要想當然地認為第一層必須執行在單獨的機器上或者單獨的程序中。

除此之外，每一層的**只能通過定義良好的介面與另一層的**進行互動。典型的情況是在獨立的**庫（dlls）中從物理上實現某些層。

總結：分層結構允許在不影響其他層的情況下修改某一層的實現。同時，它也允許將來從物理上靈活地分隔各個層。

但是，不應該輕易決定在獨立程序或機器上執行每一層。如果你決定對某一層進行分布處理，那麼必須進行特殊的分布設計。分布設計有5個原則，請詳見《分布式設計的5個原則》。