《微軟應用架構指南 (第2版)》 - 學習筆記

**《微軟應用架構指南 (第2版)》

========== ========== ==========
[做者] (美) Patterns & Practices
[譯者] (中) 朱曄 高翔 王敏
[出版] 電子工業出版社
[版次] 2010年11月 第1版
[印次] 2010年11月 第1次 印刷
[訂價] 69.00元
========== ========== ==========

【前言】

(P001)

開發人員和方案解決架構師一般是遊走在「黃金方案」和「即時方案」之間。

架構就是利用現有的技術和工具來創造儘量多的商業價值，一方面關注現有業務所提出的需求和限制，另外一方面着眼於將來經過可伸縮性、靈活性以及可維護性等方面最大化價值。

【第01章】 【什麼是軟件架構】

(P003)

軟件應用架構是一個結構化解決方案，這種結構化解決方案一方面能夠知足全部技術和運營需求，另外一方面能夠知足常見的質量特性 (quality attribute) 要求，例如性能、安全以及可管理性等。它涵蓋了受多重因素影響的一系列決策，每種決策對質量、性能、可維護性及應用程序整體的成功都有至關大的影響。

(P004)

一個失敗的架構帶來的風險包括軟件不穩定、不能支持既有或未來的業務需求、或難以在生產環境中部署和管理。

系統在設計的時候須要考慮用戶、系統 (IT基礎結構) 和業務。對於每個方面，您都應該列出關鍵應用場景，並找出重要質量特性 (例如可靠性或可伸縮性) 和使人滿意或不滿意的關鍵點。若是可能的話，在每個須要考慮的方面，都創建衡量得失的標準。

架構關注構成應用程序的主要元素和組件的使用和它們之間的交互。而設計則主要關注與數據結構和算法的選擇，以及組件細節的實現。

架構師必須考慮設計決策致使的整體效果，以及與生俱來的權衡，包括衆多質量屬性之間的權衡和用戶、系統和業務需求之間的權衡。

要記住，架構應該 :

1. 展現系統的結構可是隱藏實現細節；
2. 意識到全部用例和應用場景；
3. 力求顧及各參與者的需求；
4. 處理功能和質量需求；

(P005)

使用那些在大量解決方案中通過驗證的，能夠解決常見問題的模式。

不要對架構進行過分設計，尤爲是不要針對那些沒法驗證的事情作出任何假設，咱們只須要在設計的過程當中爲未來可能的變化留出餘地便可。

【第02章】 【軟件架構的關鍵原則】

(P007)

架構注重把組件進行組織以支持特定功能。

(P008)

在設計應用程序或系統的時候，軟件架構師的目標是經過把設計分割爲不一樣的關注點來儘可能減小複雜度。

對於每個點，咱們設計的組件就關注此特定點，不該混合其餘關注點的代碼。

(P009)

關注點分離 —— 把您的應用程序分解爲儘量不發生功能重疊的不一樣特性。這樣作最大的好處是某個特性或功能能夠獨立於其餘特性或功能進行優化。

明確層之間如何通訊 —— 若是容許應用程序中的層和其餘全部層進行通訊或依賴，可能會致使解決方案更難理解和管理，須要考慮清楚層間的依賴和層與層間數據的流動。

組件或對象不該該依賴其餘組件或對象的內部細節 —— 每個組件或對象應該只調用另外一個組件或對象的一個方法，而且這個方法知道如何處理請求，如何把它轉發到合適的子組件或其餘組件，這有助於建立可維護性和可適應性更高的應用程序。

(P010)

確保橫切代碼儘量從應用程序業務邏輯中抽象出來 —— 橫切代碼指的是有關於安全、通訊或諸如日誌和指示器等運營管理的代碼。

(P011)

每個應用程序設計都必須考慮安全性和性能，但不是每個設計都須要考慮互操做性和可伸縮性。

【第03章】 【架構模式和風格】

(P013)

架構風格 (architectural style) 有時候又被稱做架構模式，它是一組原則 —— 爲一族 (a family of) 系統提供抽象框架的粗粒度的模式。

理解架構風格有不少好處，最大的好處在於它提供了通用表達方式，還爲技術無關的討論提供了機會，能讓咱們在不涉及具體細節的狀況下針對模式和原則進行高層的討論。

(P014)

軟件系統的架構幾乎都不會侷限於單個架構風格，而一般是使用架構風格的組合來構成完整的系統。

(P016)

最簡單的 客戶端 / 服務端 系統包含了能夠由多個客戶端直接訪問的服務端應用程序，也稱做兩層架構風格。

(P017)

可使用諸如依賴注入 (Dependency Injection) 模式或者是服務定位器 (Service Locator) 之類的設計模式來管理組件之間的依賴關係，而且提供鬆散的耦合和重用。

(P018)

爲應用程序進行正確的分層能夠幫助您有效地分離關注點，從而增進靈活性和可維護性。

分層架構風格一般稱爲重用的倒金字塔 (inverted pyramid of reuse) ，每一層對直接下層的職責和抽象進行聚合。對於嚴格的分層結構來講，層中的組件只能和相同層或直接下層中的組件進行交互，而較鬆散的分層結構則容許層中的組件和相同層以及任何下屬層中的組件進行交互。

應用程序的層可能放在相同的物理機器上 (相同物理層) 或是分佈在獨立的機器上 (N 物理層)，而且每一層中的組件經過明肯定義的接口來和其餘層中的組件進行通訊。

可重用 —— 下層對上層沒有依賴，這也就使得下層能夠在其餘應用場景中被重用。

鬆耦合 —— 層之間的通訊基於抽象和事件，這也就提供了層和層之間的鬆耦合。

(P019)

性能 —— 經過把邏輯層分佈到多個物理層中能夠提升擴展性、容錯性 (fault tolerance) 和性能。

(P020)

消息總線架構一般使用消息路由或 發佈 / 訂閱 模式，而且一般使用諸如消息隊列的消息系統來實現。

複雜的處理邏輯 —— 能夠經過整合一組小的操做來構成複雜操做，每個小操做都完成特定任務，多個小操做組合成一個多步操做。

(P021)

N 層或三層是一種架構部署風格，它以一種和分層風格很類似的方式把功能分割爲不一樣的片斷，只不過每一個片斷做爲一個物理層，將會分佈在物理上分離的計算機上。它從面向組件的方式發展而來，一般使用特定於某個平臺的方式而不是基於消息的方式來通訊。

N 層應用架構的主要特徵是 : 應用程序功能分離，服務組件、組件的分佈式部署，提供加強的可伸縮性、可用性、可管理性及充分利用資源。除了直屬上層和下層以外，每個物理層徹底獨立於其餘的層。n 層只知道如何處理 n+1 層的請求，如何把請求返回給 n-1 層 (若是有的話) ，以及如何處理請求的結果。通常層之間的通訊是異步的，以便更好地支持可伸縮性。

N 層架構一般至少有三個分離的邏輯部分，每一部分都部署於獨立的物理服務器上，每一部分負責特定的功能。在使用分層設計方式的時候，若是有超過一個服務或應用程序使用邏輯層的功能就把它部署爲物理層。

N 層 / 三層 架構風格的主要優點在於 :

1. 可維護性 —— 因爲每一層相對於其餘層來講是獨立的，更新或修改部分都不會對整個應用程序發生影響；

2. 可伸縮性 —— 因爲物理層基於邏輯層來部署，橫向擴展應用程序就變得至關簡單；

3. 靈活性 —— 因爲每一層都獨立管理和擴展，也就增長了靈活性；

4. 可用性 —— 應用程序可使用易於擴展的組件來造成模塊化的系統，增長了可用性；

(P022)

經過使用一系列的協議和數據格式來交流信息， SOA 架構風格能夠把業務處理包裝成可互操做的服務，客戶端和其餘服務能夠訪問運行於相同物理層的本地服務，也能夠經過鏈接的網絡訪問遠程服務。

【第04章】 【架構和設計的方法】

(P026)

架構過程應該是迭代和增量的方式。

(P027)

在架構和設計的過程當中，用例 (use case) 描述的是一組交互行爲，它能夠是系統和一個或多個因素 (用戶或另一個系統) 之間的交互。而應用場景 (scenario) 描述的是廣義上用戶和系統的交互，這種交互並不經過用例的路徑。

(P028)

架構風格是一組原則。您能夠把它認爲是一個粗粒度的模式，它能夠爲一族系統提供抽象框架。每個風格定義了一組規則，它指定構成系統的組件類型、組件之間的關係、組裝方式的約束以及組裝時使用的一些假想。

架構風格能夠提升系統的分層程度，而且經過爲常常發生的問題提供解決方案來提高設計的重用性。

應用程序每每使用多個風格的組合。

(P029)

在選擇您設計中會使用的技術的時候，您須要考慮哪些技術能夠支持所選的架構風格、應用程序類型及應用程序的關鍵質量特性。

是否能夠畫出架構很重要。

【第05章】 【分層應用程序指導原則】

(P039)

層關注的是組件和功能的邏輯劃分 (logical division) ，不考慮組件的物理位置。層能夠位於不一樣的物理層也能夠屬於相同的物理層。

咱們須要理解邏輯層 (layer) 和物理層 (tier) 的區別。邏輯層描述的是應用程序中功能和組件的邏輯分組；而物理層 (Tier) 描述的是把功能和組件從物理上分佈到獨立服務器、計算機、網絡或遠程位置。

把超過一個邏輯層放在同一個物理機器上 (一個物理層) 很常見。

層有助於區分組件進行的不一樣類型的任務，這樣使得咱們的設計能夠很容易支持組件重用。

每個邏輯層包含許多獨立的組件類型並分組成子層，每個子層執行特定類型的任務。

把應用程序分割爲具備不一樣角色和不一樣功能的層不只有助於最大化代碼的可維護性，並且能經過改變部署方式最優化應用程序的工做方式，以及提供一個清晰的描述展現各個位置上必須實現的技術或設計決策。

從最高級的和最抽象的角度來講，任何系統在邏輯架構層面均可以看做是把一組相互協做的組件分組成邏輯層。

(P040)

表現層 —— 這個層包含面向用戶的功能，負責管理用戶和系統之間的交互，一般還包含一些組件，咱們能夠利用這些組件來訪問封裝在業務層的核心業務邏輯。

業務層 —— 這個層實現了系統的核心功能而且封裝了相關業務邏輯。它一般由一些組件構成，一些組件可能會暴露服務接口供其餘調用者使用。

數據層 —— 這一層提供針對寄存在系統邊界內的或者由其餘聯網系統暴露的數據的訪問，這種訪問多是經過服務的方式進行的。

從較高的層面來看，基於服務的解決方案能夠看做是由多個服務構成，每個服務經過傳遞消息和其餘服務進行通訊。從概念上來講，服務能夠看做是整個解決方案的一些組件。然而，在內部每個服務和其餘任何應用程序同樣都由軟件組件構成，而且這些組件能夠在邏輯上分組爲表現層、業務層和數據層。

(P041)

若是應用程序必須爲其餘應用程序提供服務，或者要實現一些直接提供給客戶端的特性，一般的方式就是使用服務層來暴露應用程序的業務功能。

(P042)

在設計應用程序的時候，第一件事情就是關注最高層次的抽象，也就是功能的分層，而後必須爲每一層 (取決於設計的應用程序的類型) 定義公共接口。定義了層和接口以後，還必須決定應用程序的部署方式，最後選擇要使用的通訊協議，用於邏輯層和物理層之間的交互。

使用分層的方式能夠改善應用程序的可維護性，而且在須要改善性能的時候能夠更方便地進行橫向擴展 (scale out) 。

肯定分層策略中相當重要的第一步就是爲應用程序肯定合適的分層粒度。

(P043)

爲了保持靈活性，老是須要確保層之間的交互是鬆耦合的。

採用分層方式會增長一些複雜度，而且可能會增長初始的開發時間，可是若是正確實施的話，會極大提升應用程序的可維護性、可擴展性和靈活性。必須在重用性、鬆耦合和影響性能、增長複雜度之間進行權衡選擇。整體上來講，分層設計提供的靈活性和可維護性的優點遠遠超過了使用不分層的緊密耦合設計帶來微弱的性能上的提高。

業務應用程序中最多見的做法是把表現、服務、業務和數據訪問功能分紅獨立的層。一些應用程序還引入報表、管理或基礎結構層。

若是須要增長層的話請慎重考慮，若是對相關聯的組件進行邏輯分組不能明確增長應用程序可維護性、可伸縮性或靈活性的話，就不該該增長層。

只有在必要的時候才應該跨越獨立的物理層來分佈邏輯層和組件。

(P044)

找出應用程序中全部橫切關注點很重要，儘量爲每個關注點設計獨立的組件。這種方式能夠幫助您得到更好的重用性和維護性。

在爲層定義接口的時候，首要的目標是實現層之間的鬆耦合。也就是說層不該該暴露內部細節讓其餘層進行依賴。而是應該設計層的接口，經過提供可以隱藏層中組件細節的公共接口來最小化依賴。這種隱藏稱做抽象 (abstraction) ，而且有不少不一樣的方式來實現。

(P045)

一個層不會依賴於另一個層，層都依賴於公共接口。

【第06章】 【表現層指導原則】

(P047)

表現層包含的組件能夠實現和顯示用戶界面而且管理用戶交互。它包含一些用於用戶輸入和顯示的控件及一些組織用戶交互的組件。

(P049)

緩存是用來提升應用程序性能和 UI 響應速度最好的方法之一。

(P050)

對長時間運行的行爲，要爲用戶提供進度反饋。考慮容許用戶取消長時間運行的操做。

(P051)

除非捕獲的異常能處理，不然別隨便使用自定義的異常，而且不要使用異常來控制應用程序的邏輯流程。

(P052)

輸入驗證應該由表現層來處理，而業務規則驗證應該由業務層來處理。

若是您的業務層和表現層在物理上是分離的，業務規則的驗證邏輯還應該在表現層也實現一份，以提升可用性和響應速度。

(P055)

對於 ASP.NET ，要當心地使用 ViewState ，由於它可能會在每一次往返中增長數據量，下降應用程序的性能。應考慮配置頁面使用只讀會話，甚至能夠的話，考慮不使用會話。

【第07章】 【業務層指導原則】

(P060)

要最大化重用，業務邏輯組件不該該包含任何只能用於特定用例或應用場景的行爲或應用程序邏輯。

在設計業務層的時候，軟件架構師的目標是經過把任務分紅不一樣的關注點來最小化複雜度。

對於每個點，您設計的組件都應該關注在特定點上，而且不該該包含和其餘關注點相關的代碼。

應該儘量使用獨立的業務層來提升應用程序的可維護性。

若是業務層會同時被表現層和外部應用程序使用，就能夠選擇經過服務來展現業務層。

(P061)

爲業務層建立接口的時候使用抽象原則最小化耦合。抽象的技術包括使用公共對象接口，通用接口定義，抽象基類或消息。

爲業務層設計有效的身份驗證策略對應用程序的安全性和可靠性很重要。

爲業務層設計有效的受權策略對應用程序的安全和可靠性很重要。

(P062)

對於角色，應考慮儘量讓粒度變小以減小須要的權限組合數量。

爲業務層設計合適的緩存策略對於應用程序的性能和響應速度很重要。

只緩存很是必要的數據。

在爲業務層設計組件的時候，應確保它們是高內聚的，而且層間是低耦合的。這樣就能夠提升應用程序的可擴展性。

(P063)

爲業務層設計有效的異常管理解決方案對應用程序的安全性和可靠性很重要。

爲業務層設計有效的日誌、審計和度量解決方案對應用程序的安全性和可靠性很重要。

爲業務層設計有效的驗證解決方案對應用程序的可用性和可靠性很重要。

【第08章】 【數據層指導原則】

(P068)

必須肯定一個策略來從數據源填充業務實體或數據結構，而且讓應用程序的業務層或表現層來使用。

(P069)

批量處理數據庫命令能夠提高數據層的性能。每一次對數據庫執行環境的請求都產生一次開銷。經過批量化能夠提升吞吐量、減小延遲以下降總開銷。由於數據庫能夠爲相近的查詢緩存而且重用執行計劃，因此批量處理類似查詢能夠提高性能。

(P070)

若是數據以數據流形式來存儲和獲取，能夠認爲這是二進制大對象或 BLOB 。

BLOB 通常用來存儲圖片數據，可是還能夠用來保存對象的二進制表示。

選擇合適的數據格式來提供和其餘應用程序進行互操做的機制，以及利用序列化來跨進程和跨物理機器進行通訊。數據格式和序列化特別重要的另一個緣由是能讓業務層存儲和獲取應用程序狀態。

(P071)

儘量在貫穿應用程序的橫切組件中集中進行異常處理邏輯。

(P072)

從存儲過程的安全和性能來講，原則上應該使用參數化查詢和避免存儲過程當中構建動態 SQL 。

要記住在存儲過程當中使用動態 SQL 可能會影響性能、安全性和可維護性。

(P073)

事務是把一組有序信息的交換和相互關聯的行爲看成原子單元，以知足請求和確保數據庫完整性。只有當全部的信息和行爲都完成，而且相關數據庫改變永久生效的時候，才認爲事務完成了。在遇到錯誤時，事務支持撤銷 (回滾) 數據庫行爲，這有助於保持數據庫中數據的完整性。

(P074)

默認狀況下微軟 SQL Server 數據庫爲每個單獨的 SQL 語句做爲一個單獨的事務來執行 (自動提交事務的模式) 。

設計有效的輸入和數據驗證策略對於應用程序的安全相當重要。

(P075)

DataReader 很是適合只讀向前的、每一行都能快速處理的操做。

若是您訪問的是 SQL Server 2008 ，可用 FILESTREAM 來獲得訪問 BLOB 數據的可能和更大的存儲靈活性。

(P076)

除非要考慮可擴展性和安全性，不然可把數據訪問層和業務邏輯層放在相同的物理層中來以提升應用程序的性能。

【第09章】 【服務層指導原則】

(P081)

若是要經過服務提供應用程序功能的話，把服務功能分割爲獨立的服務層很重要。

在服務層中須要定義和實現服務接口和數據契約 (或消息類型) 。更重要的是要記住服務永遠不該該暴露應用程序中內部的處理細節或使用的業務實體。

服務層應該提供翻譯組件翻譯業務層實體和數據契約之間的數據格式。

(P082)

服務把服務接口暴露給消息接收方。您能夠把服務接口看做一個外觀，它把應用程序內實現的業務邏輯 (通常是業務層中的邏輯) 暴露給潛在的消費者。

(P085)

冪等的端點確保了只會處理一個消息，重複的消息會被忽略。

(P086)

服務接口表示的是服務暴露的契約。契約定義了您的服務支持的操做以及這些操做相關的參數和數據傳輸對象。

對於服務接口的設計最大的錯誤就是把服務看成細粒度操做的組件。

(P087)

具象狀態傳輸 (REST) 和 SOAP 表明了兩種不一樣的實現服務的風格。從技術角度來講， REST 是一種架構模式，它使用簡單的動詞來構建，而且很適合 HTTP 。雖然 REST 架構原則能夠應用到非 HTTP 的協議上，可是實踐中 REST 實現一般和 HTTP 聯合使用。 SOAP 是基於 XML 的消息協議，能夠和任何通訊協議一塊兒使用，包括 HTTP 。

(P089)

爲了簡單，可以使用 ASP.NET WEB 服務 (ASMX) ，可是必須有運行微軟 Internet 信息服務 (IIS) 的服務器。

若是您須要諸如可靠會話、事務、活動跟蹤、消息日誌、性能計數器以及支持多種傳輸協議等高級特性的話，可考慮使用 WCF 服務。

若是您肯定爲服務使用 WCF :

1. 若是您但願和非 WCF 或非 Windows 客戶端進行互操做，可考慮使用基於 SOAP 規範的 HTTP 傳輸；

2. 若是您但願支持局域網內客戶端，可考慮使用 TCP 協議和二進制消息編碼以及傳輸安全和 Windows 驗證；

3. 若是 WCF 客戶端位於相同機器，可考慮使用命名管道協議和二進制消息編碼；

【第10章】 【組件指導原則】

(P096)

應用程序的每一層都會包含一系列用於實現該層功能的組件。這些組件應該是高內聚鬆耦合的，以簡化重用和維護。

【第11章】 【設計表現組件】

(P103)

UI 的需求取決於應用程序須要支持的功能及用戶指望。

對於技術的選擇有一個很重要的因素，那就是 UI 須要的功能。

(P104)

根據 UI 的需求，能夠肯定應用程序的 UI 類型。有許多不一樣的 UI 類型，每一種都有其優缺點。

富客戶端移動應用程序能夠支持離線的或間歇性的在線應用場景。而 Web 或瘦客戶端移動應用程序只支持持續連續的應用場景。

富互聯網應用程序 (RIA) 一般是具備豐富圖形用戶界面而且運行於瀏覽器中的 Web 應用程序。

若是應用程序的內容須要被 Web 搜索引擎搜索， Web 應用程序就很適合了。

基於控制檯的應用程序提供了純文字的用戶體驗，通常運行在諸如命令和窗口或 PowerShell 的命令行外殼中。它們最適合於管理或開發任務，不太可能做爲分層應用程序設計的一部分。

在爲 UI 組件肯定了 UI 類型以後，還必須選擇合適的技術。

(P105)

WPF 應用程序經過分離 UI 和底層控制邏輯爲 開發人員 / 設計人員 提供交互 —— 容許開發人員關注業務邏輯，而設計人員關注觀感。

Silverlight 天生就支持異步 JavaScript 和 XML (AJAX) ，它在 Web 頁面中經過 JavaScript 暴露其對象模型，可使用這項技術讓 Web 頁面組件和 Silverlight 應用程序進行交互。

(P106)

AJAX 是 .NET 框架 3.5 以及以後版本中 ASP.NET 的重頭戲。

Silverlight 控件和包含控件的 Web 頁面能夠經過使用 JavaScript 來進行交互。

在爲 UI 選擇實現技術以後，下一步就是設計 UI 組件和表現邏輯組件。

UI 組件是一些給用戶顯示信息以及接受用戶輸入的視覺元素。在表現分離模式中，它們通常指視圖。

(P107)

除非須要特殊的顯示或特殊的數據集合，不然儘可能避免建立自定義控件。若是發現 UI 需求不能使用標準控件來實現，可考慮購買控件開發包而不是去本身寫自定義控件。若是您必須建立自定義控件，儘量擴展既有控件而不是去建立新的控件。考慮經過附加控件的行爲對控件進行擴展，而不是從控件繼承，而且考慮爲自定義控件實現設計器支持，讓開發人員更容易使用。

表現邏輯組件處理用戶界面的非可視化方面的問題。包括驗證、響應用戶行爲、 UI 組件之間的通訊以及組織用戶交互。

若是 UI 須要複雜的處理或必須和其餘層進行通訊，可以使用表現邏輯組件來和 UI 組件的處理進行解耦。

表現模型組件以一種表現層中 UI 和表現邏輯組件可以使用的方式來表示業務層中的數據。

(P108)

表現模型組件應該儘量同時封裝業務層中的數據以及業務邏輯和行爲。

特定數據綁定技術可能須要數據源實現特定接口或事件來徹底支持數據綁定，好比 WPF 中的 INotifyPropertyChanged 或 Windows Forms 中的 IBindingList 。

【第12章】 【設計業務組件】

(P113)

設計業務組件是一項很重要的任務，若是沒有能正確地設計您的業務組件，那麼代碼將變得難以維護和擴展。

(P114)

應用程序的總體設計和應用程序的類型決定了使用哪些業務組件來處理請求。

【第13章】 【設計業務實體】

(P119)

通常只在表現層須要或邏輯必須和基於 XML 的數據合做的時候才用 XML 。

要注意使用和操做 XML 會消耗大量的內存。

(P120)

微軟 .NET 框架提供了能夠把 XML 數據反序列化成對象及把對象序列化成 XML 的組件。

必須肯定如何跨邊界傳輸業務實體。在大多數狀況下，當跨諸如 AppDomain 、進程以及服務接口邊界等物理邊界傳輸數據時，您都必須進行數據序列化。甚至在跨邏輯邊界傳輸數據時都要考慮進行序列化。

數據傳輸對象 (DTO) 是一種設計模式，它能夠把多個數據結構打包成單個結構以進行跨邊界傳輸。

(P121)

領域模型使用實體、值對象、聚合根、資源庫以及領域服務進行表達，並將其組織成被稱做界定的上下文 (bounded context) 的職責分塊。

實體 —— 是領域模型中的對象，它們有惟一的標識而且在軟件狀態發生改變時不會改變。實體封裝了狀態和行爲。

值對象 —— 是領域模型中的對象，用於描述領域驅動的某個方面。它沒有惟一標識並且是不可變的。

聚合根 —— 是一種類型的實體，它把邏輯上相關的子實體或值對象分組在一塊兒，並對它們進行訪問控制以及協調它們之間交互關係。

資源庫 —— 負責接收和保存聚合根，通常使用 對象 / 關係 (ORM) 映射框架。

領域服務 —— 表示操做、行爲或業務過程，而且提供引用領域模型中其餘對象的功能。有的時候，某個功能或領域的某個方面不能映射到任何具備特定生命週期或實體的對象中，這種類型的功能能夠聲明爲領域服務。

【第14章】 【設計業務工做流】

(P123)

有三種基本的工做流風格 : 順序、狀態機以及數據驅動。對於順序工做流，任務在指定的一組步驟內遷移，直到其完成。對於狀態機工做流，活動被定義成一組狀態和事件，事件會將活動由一個狀態遷移到另外一個狀態。對於數據驅動工做流，活動則根據數據相關的信息執行。所以，在設計工做流組件時，第一步是要理解您必須支持的工做流風格。

(P124)

你可使用代碼、標記語言或代碼和標記語言組合的方式來編寫工做流。採用何種方式取決於您解決方案編寫模式的需求。

WF 提供了以開發人員爲中心的解決方案，用於建立順序、狀態機以及數據驅動工做流。它支持純代碼、代碼分離及標記編寫模式。

(P125)

BizTalk 支持順序、狀態機和數據驅動工做流，以及代碼分離和標記編寫模式。

(P126)

微軟企業服務總線 (ESB) 工具包擴展了 BizTalk 的功能，它關注的是如何構建始終鏈接的、面向服務的應用程序。

【第15章】 【設計數據組件】

(P129)

數據層組件包含數據訪問組件和服務代理組件，其中數據訪問組件用於訪問系統邊界內承載數據，服務代理組件提供訪問其後端系統經過 Web 服務暴露數據。

(P130)

數據層應該利用數據訪問基礎結構統籌全部的數據源鏈接。

(P131)

無論是加密仍是明文，都不要在數據庫中保存用戶密碼以供從此驗證。您應該是保存使用了鹽值 (爲哈希的值指定一個隨機的字節) 哈希後的密碼。

【第16章】 【質量特性】

(P135)

應用程序處理諸如可用性、性能、可靠性及安全性等質量特性的優劣程度反映了設計是否成功及軟件應用程序的總體質量。

每一個系統對於每個質量特性的重視程度和優先級都不盡相同。

(P139)

延遲指的是響應任何事件以前的事件。

吞吐量指的是必定時間以內發生的事件數量。

應用程序的性能會直接影響其可伸縮性，而且缺少可伸縮性也會影響性能。

(P141)

可伸縮性是在不影響系統性能的狀況下處理額外負載的能力，或是增長負載量的能力。有兩種方式可提升可伸縮性 : 縱向伸縮 (向上擴展) 和 橫向伸縮 (向外擴展) 。若是須要進行縱向伸縮，那麼須要爲單個機器增長諸如 CPU 、 內存及磁盤之類的資源。若是須要實現橫向伸縮，那麼須要爲運行應用程序的農場增長更多機器來共享負載。

【第17章】 【橫切關注點】

(P148)

在跨物理邊界或進程邊界的時候考慮使用基於消息的通訊，在進程內 (只跨越邏輯邊界) 考慮使用基於對象的通訊。

消息隊列能夠進行事務性消息遞送及支持可靠的只發一次的遞送。

(P151)

應該儘可能讓緩存的數據靠近使用緩存的地方，這樣能夠減小處理和網絡往返過程，而且能夠最大化性能和應用程序響應速度。

【第18章】 【通訊和消息】

(P161)

爲組件解耦不只僅能夠增進可維護性，並且能夠提升靈活性，使得能夠在未來更方便改變部署策略。

因爲每一次跨邏輯或物理邊界的通訊都會增長處理開銷，所以須要經過減小往返和最小化在網絡上傳輸的數據量等方式來設計高效的通訊。

(P162)

若是須要和其餘系統進行互操做，則考慮使用 XML 序列化。可是要始終記住 XML 序列化會帶來更多的性能開銷。若是性能相當重要，那麼能夠考慮使用二級制序列化，由於它更快，而且序列化後的數據也比 XML 序列化後的數據更小。

(P165)

考慮使用 DTO 來做爲數據傳遞的一個單元，而不是每一次都傳遞獨立的數據類型。

【第19章】 【物理層和部署】

(P169)

對於非分佈式部署，除了數據存儲功能以外的全部的功能和層都在一個服務器中。

(P170)

對於分佈式部署，應用程序的各層位於獨立的物理層。這種分層機制將系統的基礎結構組織成一組物理層的方式，經過這種方式能夠針對特定運營需求和系統資源的使用狀況對特定服務器環境進行分別優化。

您須要謹記 : 增長更多的物理層也就增長了複雜度、部署工做量和成本。

您能夠利用異步調用、單向調用或消息隊列等技術來減小跨物理邊界調用時的阻塞。

(P171)

在設計分佈式環境的時候，必須肯定哪些邏輯層和組件會放到哪個物理層中。大多數狀況下，會把表現層放在客戶端或 Web 服務器上；服務、業務和數據層放在應用服務器上；數據庫則放在單獨的服務器上。

肯定在分佈式環境中如何部署組件時，能夠考慮以下指導原則 :

1. 只在必要時將組件分佈式部署。實現分佈式部署的常見緣由包括安全策略、物理約束、共享業務邏輯和可伸縮性；

2. 若是表現組件須要同步使用業務組件，那麼能夠把業務組件和表現組件部署在相同的物理層中，以最大化性能及簡化運營管理；

3. 若是出於安全性考慮，須要表現組件和業務組件之間具備信任邊界，那麼能夠把它們部署在不一樣的物理層中；

4. 除非出於安全性考慮，須要服務代理組件和調用服務代理的組件之間具備信任邊界，不然能夠考慮將它們放在同一個物理層中；

5. 儘量讓異步調用的業務組件和工做流組件部署在相同的獨立的物理層中；

6. 把業務實體和使用業務實體的組件放在相同物理層中；

(P172)

若是您正在開發一個須要訪問應用服務器的客戶端程序，或正在開發一個會訪問獨立數據庫服務器的單機客戶端程序，那麼您能夠考慮兩層模式。

(P173)

對於三層設計，客戶端會和部署在獨立服務器上的應用軟件進行交互，而應用服務器又會和位於另外一個服務器上的數據庫進行交互。對於大多數 Web 應用程序服務來講，這是最多見的部署模式，並且也能知足大多數通常的應用的須要。您可能會在客戶端和 Web / App 層之間實現防火牆，在 Web / App 層和數據庫之間又實現一道防火牆。

若是安全需求規定業務邏輯不能部署在邊緣網絡中，或是應用程序代碼須要使用大量服務器資源，您但願把相關功能的負載轉移到其餘服務器，那麼您能夠考慮四層模式。

若是出於安全方面的考慮，不能把業務邏輯放在前端 Web 服務器上，那麼能夠考慮爲 Web 應用程序使用分佈式部署。能夠爲業務層使用基於消息的接口，而且考慮使用二進制編碼的 TCP 協議來和應用層進行通訊，以得到最佳性能。還應該考慮使用負載均衡來分發請求，這樣可由不一樣的 Web 服務器來處理請求，而且要考慮在設計可伸縮 Web 應用程序時避免服務器親和性，爲 Web 應用程序設計無狀態的組件。

(P174)

對於 N 層部署，您能夠把表現和業務邏輯放在客戶端，或只把表現邏輯放在客戶端。

「縱向擴展」就是升級正在運行的硬件，而「橫向擴展」則是經過把應用程序分發到多個物理器上來分擔負載。若是打算橫向擴展，通常會使用負載均衡策略，即負載均衡集羣。

(P175)

負載均衡經過把客戶端的請求分發到多個服務器，擴展了基於服務器程序的性能，好比 Web 服務器。負載均衡技術通常指負載均衡器，接收請求，而後在必要時將其轉發至某個主機。負載均衡主機併發響應不一樣的客戶端請求，即便多個請求來自相同客戶端。

根據路由技術，負載均衡器可能會檢測到無效的 Web 服務器，而後把它從路由列表中移除，這樣能夠將失敗帶來的影響降到最低。

若是每個客戶端請求之間不須要進行跟蹤也不須要保存信息，換句話說通訊是無狀態的，那麼負載均衡集羣是最具伸縮性也是最有效率的。若是必須跟蹤狀態，那麼可能須要使用親和性技術和會話技術。

(P176)

在開發過程當中，若是使用 Internet 信息服務 (IIS) 6.0 或以上的版本，能夠配置 IIS 爲 Web 園模式，幫助確保開發的應用程序正確處理了會話狀態。

Web 服務器、 Web 農場同樣，若是業務層、數據層和表現層沒有位於相同的物理層上，能夠經過應用農場的方式來橫向擴展業務層和數據層。將從表現層過來的請求分發到農場中的每一服務器上，都有差很少的負載。根據每一層的需求及指望用戶個數的負載，應將業務層和數據層的組件放到不一樣的應用農場中。

(P179)

通常狀況下，若是打算擴展應用程序，能夠從兩種基本選擇中選擇一個或者兩個進行組合，這就是「縱向擴展」(讓盒子變得更大)和「橫向擴展」(用更多的盒子)。

對於「橫向擴展」，增長更多服務器而且使用負載均衡和集羣的解決方案。除了能處理額外的負載，「橫向擴展」應用場景還能緩解硬件故障的問題。

使用額外的處理器和增長內存的縱向擴展是一個經濟實惠的解決方案。這種方案還能夠避免引入「橫向擴展」和使用 Web 農場和集羣技術帶來的額外成本。應該先考慮「縱向擴展」選項，而且經過性能測試來檢查「縱向擴展」方案是否達到了制定的可伸縮性標準，以及是否在某種可接受的性能範圍內能支持必要的併發用戶數。

若是因爲 CPU 、 I/O 或內存上的瓶頸，爲解決方案進行「縱向擴展」不能提供足夠伸縮性，那麼必須進行「橫向擴展」和引入額外的服務器。

(P180)

具備清晰遠程接口的鬆耦合的分層設計，相比緊密耦合的混亂交互的設計，更容易進行「橫向擴展」。因爲分層設計天生就具備分離點，那麼在層的邊界進行「橫向擴展」就很是適合了。其中的訣竅是找到正確的邊界。

【第20章】 【選擇應用程序類型】

(P187)

在選擇應用程序類型的時候，您須要考慮需求、技術限制，以及最終的用戶體驗類型。

(P188)

每一個應用程序類型均可以使用一種或多種技術來實現。使用場景和技術限制，以及開發組的能力和經驗都對技術的選擇有影響。

(P191)

RIA 應用程序通常依賴於一個客戶端的插件或一個託管的執行環境 (好比 XAML 運行時或 Silverlight) 。這個插件須要和遠程的 Web 服務器進行通訊， Web 服務器能夠生成客戶端插件或執行環境所須要的代碼和數據。

【第21章】 【設計 Web 應用程序】

(P196)

在設計一個 Web 應用程序時，考慮使用一些技術，好比緩存和輸出緩衝來下降瀏覽器和 Web 服務器之間的來回通訊，以及 Web 服務器與其下游服務器之間的通訊。一個好的緩存策略多是一個很是重要的跟性能相關的設計要點。

(P198)

受權決定着一個已經經過認證的身份是否能夠執行某個任務，以及是否能夠訪問某些資源。

您應該使用緩存來優化對引用數據的查找，避免網絡往返通訊的開銷，避免沒必要要的及重複的提交。

(P200)

儘量地使用 CSS 來佈局，而不要使用基於表格的佈局。

基於表格的佈局在渲染的時候會慢一些，而且在佈局複雜的時候會出現一些問題。

將客戶端腳本放在一個獨立的腳本文件中，這樣作能夠被瀏覽器緩存。

(P201)

對於多服務器 (Web 場) 的場景，而且必須在服務器之間集中存儲 Session 數據，那麼考慮使用 SQL Server 狀態存儲。

【第22章】 【設計富客戶端應用程序】

(P209)

富客戶端的用戶界面具備高性能、高交互性以及用戶體驗豐富的特色，並可適應獨立的、連線的、偶爾可連線的以及離線的場景。

(P210)

在設計一個富客戶端應用程序的時候，軟件架構師的目標就是要選擇一項合適的技術，而後經過將任務按不一樣內容領域進行劃分，使得設計出來的結構的複雜度最小。設計必需要在性能、安全、重用性以及易維護性上知足應用程序的需求。

(P215)

有時候，儘管應用程序的其餘全部方面都表現得不錯，但一個差的用戶體驗就能產生嚴重的負面影響。所以將您的應用程序設計成從一開始就提供一種引人注目並直觀的用戶體驗是很是重要的，由於用戶體驗會被您的應用程序的架構的不少不一樣方面所影響。

儘量利用數據綁定功能來顯示數據，尤爲對於表格式的數據和多行的數據。這樣作能縮減所須要的代碼，簡化開發並減小代碼錯誤。

(P218)

Windows 窗體、 WPF 和 Silverlight 數據綁定都支持雙向綁定策略，它容許將數據結構綁定到一個用戶界面組件上向用戶顯示當前的數據，並容許用戶修改數據，而後使用用戶所輸入的值自動更新原來的數據。

【第23章】 【設計富 Internet 應用程序】

(P225)

RIA 在提供了 Web 應用程序在部署和維護性能上所擁有的大部分優勢的同時，還支持豐富的圖形和流媒體。

【第24章】 【設計移動應用程序】

(P241)

若是要構建富客戶端，那麼業務層和數據服務層可能會放在設備自身。若是要構建瘦客戶端，全部的層都要放在服務器上。

【第25章】 【設計服務應用程序】

(P255)

「服務」是指能提供一組功能的公共接口。

【第26章】 【設計託管和雲服務】

(P270)

基於雲的服務一般分爲幾種類型，例如 存儲/計算，業務服務以及 零售/批發 服務。

【第27章】 【設計 Office 業務應用程序】

(P287)

OBA 是一種企業整合應用程序。

OBA 在設計上是經過使用開放的標準、標準的文件格式和 Web 服務來進行協做。

【第28章】 【設計 SharePoint LOB 應用程序】

(P301)

SharePoint LOB 應用程序能夠被配置成經過網站的形式來發布面向 Internet 的內容，這樣網站就能夠與 Web 場的部署一塊兒向外擴展以支持大量用戶的訪問，它還能夠與 ASP.NET 集成在一塊兒，利用這些網站來顯示 LOB 數據。**