ASP.NET 設計模式（轉）

Professional ASP.NET Design Patterns

爲何學習設計模式？

運用到ASP.NET應用程序中的設計模式、原則和最佳實踐。設計模式和原則支持鬆散耦合、高內聚的代碼，而這將提高代碼的可讀性、靈活性和可維護性。
對於那些已經有很好解決方法的任務，沒有理由再去進行重複勞動。

著名建築學家克里斯托弗·亞歷山大 Christopher Alexander 曾經說過：
每種模式描述了一個在咱們周圍不斷重複發生的問題，以及該問題解決方案的核心，這樣你就能夠一次又一次地使用該方案而沒必要作重複勞動。

約翰·列儂「沒有問題，只有出路」

.NET開發人員學習的必要性
微軟的RAD(Rapid application development)開發工具Visual Studio.NET快速開發表單式Web應用程序。經過簡單的拖曳和所見即所得的應用程序設計界面，使得人們可以快速上手，一致的編程模型也有利於桌面應用程序開發者向Web應用程序開發轉移。此外，因爲編碼模式與設計模式能夠簡單地進行切換，平面設計師在設計階段就可以看到與運行時接近的界面，而沒必要頻繁地運行調試模式或刷新網頁，這使平面設計師能全程參與應用程序開發，從而提升了開發效率。然而，這種固化的表單式應用程序設計模式也存在先天不足。隨着業務需求的變化和規模的不斷增加，若是仍然把全部的業務邏輯放在後置代碼中，將使代碼日益臃腫，並且存在大量的重複代碼。同時，這種Web表單式設計也不利於在應用程序中採用AJAX技術，很難在Web表單和Web服務程序之間共享代碼。掌握書中提到的設計理念和實現工具，對於更好地理解ASP.NET MVC框架中的概念很有益處。


模式與設計原則

設計模式是高層次的、抽象的解決方案模板。能夠將這些模式視爲解決方案的藍本而不是解決方案自己。從中沒法找到一種能夠簡單地運用到應用程序中的框架；相反，一般是經過重構本身的代碼並將問題泛化來實現設計模式。

「四人組」(GoF)。他們收錄了23種設計模式並將它們概括爲3組。
●  建立型模式(Creational)：處理對象構造和引用。
●  結構型模式(Structual)：處理對象之間的關係以及它們之間如何進行交互以造成更大的複雜對象。
●  行爲型模式(Behavioural)：處理對象之間的通訊，特別是在責任和算法方面。

模式是描述複雜問題的解決方案的有效方式。若是具有設計模式的牢固知識，就能夠與團隊中的其餘成員快速、順暢地溝通，而沒必要糾結於底層的實現細節。模式是語言不可知的。經過學習模式而得到的知識將可以運用於具體編程時採用的任何優秀的面嚮對象語言。

設計模式的宗旨就是重用解決方案。固然，並不是全部問題都是如出一轍的，但若是可以將一個問題分解，並找出它與之前解決過的問題之間的類似之處，就能夠運用這些解決方案。即便您認爲本身遇到的問題是獨特的，也應該能夠經過將其分解成若干基本要素，將其泛化至必定程度，從而找出一種合適的解決方案。

設計模式的名稱很是有用，這是由於它反映出該模式的行爲和目的，併爲人們在集思廣益討論解決方案時提供經常使用的詞彙表。

陷阱：試圖把設計模式運用到所作的每件事情，但最終取得的效果卻與設計模式初衷(也就是讓事情變得簡單)相反。運用模式的較好方法是，經過識別正在試圖解決的基本問題，來尋找適合它的解決方案。


設計原則

設計原則構成了設計模式賴以構建的基礎。經過遵循通過驗證的設計原則，本身的代碼基會變得更加靈活、更可以適應變化，並且可維護性更佳。

1. 簡約原則(KISS)
軟件編程領域廣泛存在的一個問題是須要把解決方案過分複雜化。KISS原則的目標就是讓代碼保持簡潔但不要過於簡陋，從而避免引入任何沒必要要的複雜度。

2. 不要重複自已(DRY)
DRY原則的目的是經過將公用的部分抽離出來放在一個單獨的地方從而避免重複系統中的任何部分。這個原則不只涉及代碼並且包括系統中重複的任何邏輯。最終，系統中的任何一部分知識都應該只有一種表示形式。

3. 講述而不要詢問(Tell, Don't Ask)
「講述而不要詢問」原則體現了封裝以及將責任指派到正確的類這兩個思想。這個原則要求，應該告訴對象您但願它們執行什麼動做，而不是詢問有關該對象狀態的問題而後由您本身決定但願執行什麼動做。這個原則有助於匹配責任並避免類之間的緊密耦合。

4. 您不須要它(YAGNI)
YAGNI原則指的是隻須要將應用程序必需的功能包含進來，而不要試圖添加任何其餘您認爲可能須要的功能。測試驅動開發(TDD)就是一種堅持YAGNI原則的設計方法學。TDD的宗旨就是編寫測試來驗證系統的功能，而後只須要編寫可以讓測試經過的代碼便可。

5. 分離關注點(SoC)
SoC這一過程將軟件分解爲多項不一樣的功能，每項功能封裝了可供其餘類使用的惟一行爲和數據。一般，一個關注點表明類的一項功能或行爲。將程序劃分紅若干獨立職責的作法顯著提升了代碼的重用程度、維護性和可測試性。

S.O.L.I.D.設計原則是一組針對面向對象設計的最佳實踐。術語S.O.L.I.D.來自於Robert C. Martin(朋友們親切地稱呼他Bob大叔)的著做Agile Principles, Patterns, and Practices in C#中收集的5個設計原則的名稱的首字母。

1. 單一責任原則(SRP)
SRP原則與SoC原則保持高度一致。它要求每一個對象只應該爲一個元素而改變並且只有一個職責關注點。遵循這個原則，就能夠避免單體類(就像是軟件領域的瑞士軍刀)設計問題。使每一個類均保持簡潔，就能夠提高系統的可讀性和可維護性。

2. 開放封閉原則(OCP)
OCP原則要求類對於擴展應該是開放的，而對於修改應該是封閉的，這樣應該就可以在不改變類的內部行爲的狀況下添加新功能並擴展類。這個原則努力避免破壞已有的類以及其餘依賴它的類，由於這會在應用程序中形成bug和錯誤的漣漪效應。

3. 里氏替換原則(LSP)
LSP原則指出應該可以使用任何繼承類來替代父類而且讓其行爲方式保持不變。這個原則與OCP原則保持一致：它確保繼承類不會影響父類的行爲，換句話來講，繼承類必須可替代它們的基類。

4. 接口分離原則(ISP)
ISP原則關注的是將契約的方法劃分紅若干職責分組，而且爲這些分組指派不一樣的接口，這樣客戶端就不須要實現一個龐大的接口和一堆它們並不使用的方法。這個原則背後的目的是：使用相同接口的類只須要實現特定的一組方法，而不是實現一個龐大的單體方法接口。

5. 依賴倒置原則(DIP)
DIP原則的宗旨是將本身編寫的類與具體的實現隔離開來，讓這些類依賴於抽象類或接口。它提倡面向接口(而不是實現)編程，這確保代碼不會與某種實現緊密耦合，從而提升了系統的靈活性。

6. 依賴注入(DI)和控制反轉(IoC)原則
與DIP緊密相關的是DI原則和IoC原則。DI經過構造器、方法或屬性來提供底層類或從屬類。配合使用DI原則，這些從屬類能夠被反轉爲接口或抽象類，這樣就能夠造成一個具備較高的可測試性和易於修改的鬆散耦合系統。

在IoC原則中，系統的控制流與過程式編程方法相比是反轉的。這個原則的一個示例是IoC容器，它的做用是將服務注入到客戶端代碼，而沒必要讓客戶端代碼指定具體的實現。在該實例中，控制反轉指的是客戶端獲取服務的行爲。

Fowler的企業設計模式
Martin Fowler的著做Patterns of Enterprise Application Architecture是有關如何構建企業級應用程序的最佳實踐和模式的參考書。

1領域邏輯模式
組織業務邏輯的3種常見方法：Transaction Script(事務腳本)、Active Record(活動記錄)及Domain Model(領域模型)。

1. Transaction Script
Transaction Script模式按照線性的、過程式方法來組織業務邏輯。它將細粒度的業務用例映射爲細粒度的方法。

2. Active Record
Active Record模式按照一種可以緊密匹配底層數據結構的方式來組織業務邏輯，即表中表示數據行的對象。

3. Domain Model
Domain Model模式是對現實領域對象的抽象。同時對數據和行爲建模。對象之間能夠存在與真實領域相匹配的複雜關係。



2對象關係映射

支持持久化的基礎設施代碼所需的企業模式。

1. Unit of Work
Unit of Work(工做單元)模式用來維護一個由已經通過業務事務修改(添加、刪除或更新)的業務對象構成的列表。而後，Unit of Work模式負責將這些發生變化的對象的持久化工做協調成爲一個原子動做。若是出現問題，整個事務就會回滾。

2. Repository
Repository(資源庫)模式大致上用於對象的邏輯集合，它們更爲人知的名字叫作聚合(aggregate)。它充當業務實體的內存集合或倉庫，徹底將底層數據基礎設施抽象出來。

3. Data Mapper
Data Mapper(數據映射器)模式用來從原始數據中提取信息以生成對象，以及將業務對象中的信息轉換到數據庫。業務對象和數據庫彼此互不瞭解。

4. Identity Map
Identity Map(標識映射)模式監視每個從數據庫中加載的對象，確保全部對象只加載一次。當後面請求該對象時，在從數據庫檢索以前先檢查標誌映射。

5. Lazy Loading
Lazy Loading(惰性加載或延遲加載)模式將獲取資源的過程推遲到真正須要用到該資源的時候。

6. Query Object
Query Object(查詢對象)模式是GoF的Interpreter(解釋器)設計模式的一種實現。查詢對象充當一種從底層數據庫中抽象出來的面向對象查詢，它引用的是屬性和類，而不是真正的表和列。一般，還須要使用一個翻譯器對象來生成用於查詢數據庫的原生SQL語句。


Web表示模式
將領域和表示邏輯分離同時讓表示層可以有效測試的模式。這些模式的任務都是將用於表示的邏輯關注點與業務邏輯關注點分離。ASP.NET表示須要所涵蓋的模式有：

●  Model-View-Presenter(模型-視圖-表示器)。
●  Model-View-Controller(模型-視圖-控制器)。
●  Front Controller(前端控制器)。
●  Page Controller(頁面控制器)。

Fowler著做中的其餘企業模式
1. Null Object模式
Null Object(空對象)模式也稱爲Special Case(特殊狀況)模式，它充當返回值而不是向調用代碼返回null。空對象將與預期結果共享相同的接口或者從相同的基類繼承而來，這樣減小了在代碼基中處處檢查null狀況的須要。

2. Separated Interface模式
Separated Interface(獨立接口)模式要求將接口放在一個獨立於具體實現的程序集或命名空間中。這確保客戶端徹底不知道具體實現，並且可以遵循面向抽象編程(而不是面向實現)以及依賴倒置原則。

3. Gateway模式
Gateway(網關)模式容許客戶端經過一個簡化的接口來訪問複雜的資源。網關對象基本上將資源API包裝成一個可以在應用程序中處處使用的單個方法調用。此外，它還隱藏了全部的API複雜性。

--------------------------------
TDD(Test-driven Development，測試驅動設計)並不像它的名稱所言，它更多的是一種設計方法學而不是測試策略。這種設計方法學背後的主要思想是使用測試來塑造系統的設計。在建立軟件解決方案時，首先編寫一個致使測試失敗的測試程序來斷言某種業務邏輯。而後編寫代碼讓測試經過。最終，經過重構來清理全部代碼。這三步已經被人們稱爲紅-綠-重構(red-green-refactor)。紅和綠指的是測試框架分別用來顯示測試經過和測試失敗的顏色。

經過經歷TDD流程，最終將獲得一個帶有一套能夠確認全部行爲的測試的鬆耦合系統。TDD的一個副產品是這些測試提供了一種描述系統可以作什麼以及不能作什麼的文檔。由於測試屬於系統的一部分，因此它毫不會過期，這與編寫的文檔和代碼註釋不一樣。

●  Test Driven Development: By Example，Kent Beck著
●  The Art of Unit Testing: With Examples in .NET，Roy Osherove著
●  Professional Enterprise .NET，Jon Arking與Scott Millett合著(Wrox出版)

DDD(Domain-driven Design，領域驅動設計)是一組有助於構建反映對業務的理解並知足業務需求的應用程序的模式和原則。除此以外，它是一種思考開發方法學的全新方式。DDD的建模方式以下：首先經過全面理解真實領域來對真實領域建模，而後將全部的術語、規則和邏輯放到代碼的某種抽象表示中(一般是以領域模型的形式)。雖然DDD並非一種框架，可是它確實有一組構建塊或概念能夠整合到解決方案中。

●  Domain-Driven Design: Tackling Complexity in the Heart of Software，Eric Evans著
●  Applying Domain-Driven Design and Patterns: With Examples in C# and .NET，Jimmy Nilsson著
●  .NET Domain-Driven Design with C#: Problem - Design - 

BDD(Behavior-driven Design，行爲驅動設計)被視爲TDD與DDD合併的結果。BDD關注系統的行爲而不只僅是測試它。使用BDD時所建立的規範可使用在真實領域中隨處可見的語言，這可以讓技術用戶和業務用戶同時受益。

採用BDD編寫規範時產生的文檔可讓讀者瞭解系統在各類狀況下表現什麼樣的行爲，而不是簡單地驗證各個方法正在執行它們應該完成的工做。經過將DDD的若干方面與核心TDD概念有機融合，BDD將同時知足業務用戶和技術用戶的需求。可使用標準的單元測試框架來執行BDD，但專門的BDD框架已經出現了，並且BDD即將成爲下一個大事件。

怎樣學習

名稱和意圖 反映該模式或原則的目的、用法、好處以及使用該模式的動機。
UML圖
展現模式或原則的結構的圖形化表示。圖形化表示用來顯示通用的解決方案模版以及其實現。
代碼實現

如何選擇和運用設計模式
●在不瞭解模式的狀況下不能運用它們。首先擴大本身的知識面並採用從抽象到具體的方法來學習模式和原則。
●是否有必要引入設計模式的複雜性。須要衡量實現某種模式所需的時間與該模式可以帶來的收益。謹記KISS原則。
●講問題泛化，已更抽象的方式識別正在處理問題。瞭解每一個模式和原則是如何編寫的。並瞭解本身須要解決的問題是否符合特定模式或原則試圖解決的問題。設計模式是高層次的激將法解決方案，試着把問題抽象，不要過於關注具體問題的細節。
●瞭解具備相似性質的模式以及同組中的其餘模式。
●封裝變化的部分。瞭解應用程序中什麼可能發生變化。
●在選擇好設計模式以後，確保在命名解決方案中的參與者使用該模式的語言及領域語言。FedExShippingCostStrategy 使用策略模式爲不一樣的快遞公司計價

做者： Leo_wl

　　　　

出處： http://www.cnblogs.com/Leo_wl/