企業應用架構模式
響應性不同于請求處理，它是系統響應請求的速度有多快。這個指標在許多系統里非常重要，因為對于一些系統而言，如果其響應太慢，用戶將難以忍受——盡管其響應時間可能不慢。如果能夠在處理真正完成之前就給用戶一些信息表明系統已經接到請求，則響應性就會好一些。例如，進展條。
一條關于依賴性的普遍原則：領域層和數據源層絕對不要依賴于表現層。
領域邏輯的組織可以分為三種主要的模式：事務腳本、領域模型以及表模塊。
事務腳本是這樣一個過程：從表示層獲得輸入、進行校驗和計算處理、將數據存儲到數據庫中以及調用其他系統的操作等?；镜慕M織方式是讓每個過程對應用戶可能做的一個動作。所以，我們可以將這一模型想像成一個動作或業務事務的腳本。每一個動作是由一個過程來驅動。
在領域模型中，不再是由一個過程來控制用戶某一動作的邏輯，而是由每一個對象都承擔一部分相關邏輯。
在許多方面，表模塊是事務腳本和領域模型的一個中間地帶。它圍繞表而非直接圍繞過程來組織領域邏輯，提供了更多的結構，而且更容易發現和移除冗余代碼。但是，你無法應用許多在領域模型中可以使用的組織細粒度邏輯結構的技術，例如繼承、策略和其他面向對象的設計模式。
通常，序列化LOB（大對象Large OBject）對于用來組成應用程序部分的相對獨立對象群而言是***的。但如果過多使用它，最終會把數據庫弄得和事務文件系統差不多。
對于任何繼承結構，一般都有三種選擇?？梢詾橐粋€層次中的所有類建立一個表，即單表繼承；也可以為每個具體類建立一個表，即具體表繼承；或者為這個層次中每一個類建立一個表：類表繼承。
這三種方法有利有弊。單表繼承浪費空間，但避免了連接操作；具體表繼承在超類改變時不得不改變所有表，但它也避免了連接操作，允許從一個表取得一個對象；類表繼承需要多個連接操作來載入一個對象，這樣通常損失了性能，但它是類和表之間最簡單的關系。
如果機器處在屏幕流的控制下，那么你就需要應用控制器；如果這臺機器是在用戶的控制下，你就不要應用控制器。
在視圖方面，可以考慮三種模式：轉換視圖、模板視圖和兩步視圖。
對任何并發程序的本質來說，僅僅考慮正確性是不夠的，還必須考慮靈活性（即有多少并發活動可以同時進行）。人們常常需要犧牲一些正確性以獲取更多的靈活性，這取決于失敗的嚴重性和可能性以及人們對并發處理數據的需求。
并發問題有兩個非常重要的解決方案：一個是隔離（isolation），一個是不變性（immutability）。
在樂觀鎖和悲觀鎖之間進行選擇的標準是：沖突的頻率與嚴重性。如果沖突很少，或者沖突的后果不會很嚴重，那么通常情況下應該選擇樂觀鎖，因為它能得到更好的并發性，而且更容易實現。但是，如果沖突的結果對于用戶來說是痛苦的，那么就需要使用悲觀鎖策略。
超時控制和檢測機制處理已經出現的死鎖，而其他的方法則盡力防止死鎖的發生。
跨越多個請求的事務稱為長事務。
在請求開始時啟動事務，在請求結束時提交事務，這是請求事務。
另一種方法是盡可能晚打開事務。使用延遲事務時，應在事務外完成讀取數據的操作，只在修改數據的時候啟動事務。然而，這可能會導致不一致讀問題。
當可以并發執行并且結果與以某種順序依次執行的結果相同時，事務就是可串行化的（serializable）。
如果系統中有很多用戶，應該考慮使用集群來提高吞吐率。會話遷移（session migration） 允許一次會話從一臺服務器轉移到另一臺服務器，從而可以由一臺服務器處理一個請求，其他服務器處理其他的請求。與其相反的方式是服務器親和（server affinity），它要求某次特定會話的所有請求只能由同一臺服務器處理。
分布對象設計***定律：不要分布使用對象。
這種情況下，怎樣有效利用多處理器資源呢？大多數情況下是使用集群系統。在每一個處理器上都部署所有的對象并在其他幾個節點上復制它們。這樣一來，每個處理器上的對象只需用到本地調用，從而運行更快。還可以使用細粒度接口來設計對象，從而得到更簡單的編程模型和更好的可維護性。
轉載自: 博客園 - 愛拼才會贏 - benjamin超人http://www.cnblogs.com/BenjaminYao/
【編輯推薦】
