　　《.NET框架設計模式、配置、工具》總結瞭框架設計的整體思路和經驗，包含瞭常見應用框架設計的模式、框架靈活性的配置和框架工具的支持，有助於讀者瞭解框架設計的核心思想，加深對框架設計的理解，快速掌握框架設計的技巧，並在研究其他框架時能夠做到舉一反三。　　《.NET框架設計模式、配置、工具》適用於.NET程序員、架構師、項目經理、技術總監、應用層開發者、框架學習者和和對框架設計感興趣的讀者。

作者簡介

　　王清培（Plen Wang），培元教育谘詢公司創始人、架構師、高級講師，微軟C# MVP。對企業級分布式係統、大型電子商務係統有著豐富的設計開發經驗。一直是應用框架模式、企業級應用架構模式、重構、領域驅動設計方嚮的研究者和實踐者，長期在博客中分享技術經驗，連續三屆獲得全國IT技術博客大賽50強，有著極強的技術鑽研精神，並堅持毫保留地將經驗分享齣來。　　曾任職北美的電子商務巨頭公司美國新蛋網，從事平颱的重構和設計工作。目前就職於國內的上市在綫旅遊企業攜程旅行網，負責框架、服務相關的設計開發工作，以及培元的課程教育和企業培訓。

內頁插圖

第1章　框架設計的基本概念　　
1．1　框架　　
1．1．1　框架的通常作用及層麵　　
1．1．2　框架的生命周期　　
1．2　框架設計　　
1．2．1　確定問題域和識彆變化點　　
1．2．2　選擇閤適的架構模式、配置變化數據、可視化管理　　
1．3　框架設計核心三元素：模式、配置和工具　　
1．3．1　框架模式　　
1．3．2　框架配置　　
1．3．3　框架工具　　
1．3．4　總結　　

第2章　C#、．NET Library高級應用　　
2．1　重溫C#--靈活運用各元素　　
2．1．1　類、繼承、接口　　
2．1．2　字段、屬性、常量、枚舉　　
2．1．3　方法、委托、事件　　
2．1．4　泛型、協變/逆變、類型推斷　　
2．1．5　擴展方法　　
2．1．6　部分類、部分方法　　
2．1．7　特性、元數據　　
2．1．8　反射、代碼對象模型、動態編譯、動態緩存　　
2．2　麵嚮C#設計模式的關鍵技術　　
2．2．1　創建型--工廠模式、工廠規則注入、委托工廠　　
2．2．2　行為型--觀察者模式、基於事件的觀察者　　
2．2．3　結構型--橋接模式、擴展方法　　
2．3　編碼時應注意防禦性、穩定性和性能　　
2．3．1　常被忽視的防禦性判斷　　
2．3．2　避免直接返迴NULL，保持80%的穩定性　　
2．3．3　空對象模式和擴展方法的NULL驗證　　
2．3．4　注重性能的編碼方式　　
2．4　單元測試、可測試性代碼、持續重構　　
2．4．1　單元測試的重要性及核心意義　　
2．4．2　可測試性代碼的重點　　
2．4．3　類中受保護方法的測試　　
2．4．4　基於完善的單元測試用例　　
2．4．5　TDD的優勢　　
2．5　第三方庫是可插撥的、依賴庫的版本　　
2．5．1　依賴抽象接口　　
2．5．2　依賴庫的版本　　

第3章　框架模式--框架的精髓　　
3．1　提供程序模式　　
3．1．1　問題域和基本模型　　
3．1．2　相關的設計模式　　
3．1．3　實例　　
3．1．4　總結　　
3．2　鏈式編程模式　　
3．2．1　問題域和基本模型　　
3．2．2　實例--非擴展方法實現鏈式編程模式　　
3．2．3　實例--擴展方法實現鏈式編程模式　　
3．2．4　配置帶有算法的邏輯並將邏輯算法作為配置保存　　
3．2．5　鏈式編程模式在領域模型中的價值　　
3．2．6　總結　　
3．3　管道模式　　
3．3．1　問題域和基本模型　　
3．3．2　實例　　
3．3．3　自治管道與約定管道的區彆　　
3．3．4　總結　　
3．4　邏輯上下文模式　　
3．4．1　上下文相關概念　　
3．4．2　問題域和基礎模型　　
3．4．3　實例　　
3．4．4　總結　　
3．5　鈍化程序模式　　
3．5．1　問題域及基礎模型　　
3．5．2　實例　　
3．5．3　總結　　
3．6　規則外掛模式　　
3．6．1　問題域及基礎模型　　
3．6．2　調整邏輯架構--分離業務邏輯於業務規則　　
3．6．3　實例　　
3．6．4　總結　　
3．7　語句組件模式　　
3．7．1　問題域和基礎模型　　
3．7．2　實例　　
3．7．3　總結　　
3．8　麵嚮契約式模式　　
3．8．1　問題域和基礎模型　　
3．8．2　契約條目檢查器　　
3．8．3　麵嚮查詢的契約文件　　
3．8．4　實例　　
3．8．5　總結　　
3．9　異步消息事件驅動模式　　
3．9．1　問題域及基礎模型　　
3．9．2　相關的設計模式　　
3．9．3　實例　　
3．9．4　總結　　
3．10　總綫消息路由模式　　
3．10．1　問題域及基礎模型　　
3．10．2　實例　　
3．10．3　總結　　
3．11　元數據及元數據緩存池模式　　
3．11．1　問題域及基礎模型　　
3．11．2　元數據的生成方式　　
3．11．3　實例　　
3．11．4　總結　　

第4章　配置化--提高靈活性及擴展性　　
4．1　配置內容及存放位置　　
4．1．1　配置內容　　
4．1．2　存放位置　　
4．2　配置的領域概念及文檔對象模型　　
4．2．1　傳統領域信息配置項　　
4．2．2　設計具有領域概念的配置項　　
4．2．3　配置相關的文檔對象模型（DOM）　　　
4．3　動態代碼配置　　
4．3．1　模闆引擎介紹　　
4．3．2　動態代碼配置　　

第5章　工具--可視化使用　　
5．1　設計時工具
5．1．1　自動代碼生成　　
5．1．2　暴露框架中的某個工具支撐庫　　
5．2　運行時工具特性　　
5．2．1　腳本引擎　　
5．2．2　執行上下文　　
5．2．3　可插拔　　

第6章　框架設計總結　　

精彩書摘

　　2．3．4注重性能的編碼方式　　在編寫代碼時，要保持資源釋放的警惕性，時刻提醒自己如何提高性能，至少要做到減少無辜資源的浪費。要做到上述幾點，其實最重要的就是資源的釋放，不及時釋放資源極易導緻服務器內存被吃光的危險。　　這裏我們介紹幾種資源使用和釋放的方法，隻要適當地運用，就可以大大減少內存齣問題的可能性。　　1。在對象使用時再實例化　　對象在使用時再實例化，而不是在類加載的時候就實例化。可以把實例化的工作放在構造函數中或者初始化的方法中，如果不是及時需要的對象，建議使用延遲加載的方式。　　2．在對象不使用時及時設置為NULL　　當對象不需要再使用時，應該在第一時間內將其設置為NULL，這樣可以方便GC：及時地迴收該對象所占用的內存。　　．NETGc算法用的並不是“引用計數”，而是“標記與清除”，所以你不必擔心你所設置為NuLL的對象是否會被及時地迴收。“標記與清除”算法是從應用程序域的根對象開始計算一個對象可達樹。顯然，如果是不能夠被訪問的對象就會被.NETGc認為是垃圾，將被迴收掉。而“引用計算”算法，是計算每個對象的引用計數，所以哪怕這個對象有任何一個引用關係存在，都不會被釋放掉，這種算法經常會導緻內存泄漏。而.NETGC的“標記與清除”算法不會管你的引用關係，哪怕有一群對象彼此互相連接，但是這群對象是孤立的，從應用程序域根對象開始計算可達樹，隻要中問斷開瞭與這群對象的可達，那麼這群對象同樣會被.NETGc迴收。　　3．使用IDisposable接口來聲明有重要資源需要及時釋放　　IDisposable接口是用來聲明該對象內部有重要的資源需要在不使用時及時釋放的，像數據庫連接、消息池對象，這些都是很重要、很有限的係統資源。如果稍微使用不當，這些關鍵性的對象會立馬讓係統整體癱瘓、內存吃光或者cPul00％處理中，而你為瞭定位具體是哪個對象在使用時齣瞭問題，就不得不使用WinDebug，之類的工具去仔細地查看對象的內存狀態和cPu狀態。　　尤其是當對象使用到瞭本地非托管資源時，一定要記住及時地實現IDisposable接口，而使用者也一定要及時地調用IDisposable．Dispose（）方法或者使用using（）語句來自動地釋放資源。　　2.4單元測試、可測試性代碼、持續重構　　本節將介紹單元測試的意義，讓大傢明白重構是需要單元測試作為保障纔得以實施的。大部分開發人員不明白單元測試的意義，也不懂得如何去寫單元測試，所以也就談不上把重構運用到項目的開發中去。　　本節將循序漸進地勾畫齣重構與單元測試之間的藝術性，讓大傢徹底明白單元測試技術的重要性。　　為瞭更好地理解本節內容，我們最好帶著以下問題來閱讀。　　第一，你是否曾想過對某段邏輯進行重構，但是不敢改？　　第二，你是否曾抱著很多設計模式、重構模式滿懷信心地準備進行大麵積的代碼修改，結果卻是無法下手對以往代碼做任何微小修改？是不是會覺得自己所學的這些技術沒有什麼實際用處，從而導緻你對學習失去瞭信心？　　第三，你是否無法深刻理解敏捷開發到底改變瞭現在開發的哪些方麵，到底敏捷在哪裏？　　第四，你是否無法明白彆人所說的“持續重構齣核心領域模型”的過程到底是怎樣的？　　如果你有上述疑問，那麼學習本節內容之後，這些問題就會迎刃而解。　　2．4．1單元測試的重要性及核心意義　　首先需要說明的是，單元測試並不隻是為瞭驗證你目前所寫的代碼有沒有問題，它更為重要的作用是，你一次編寫好的測試用例是否可以在日後隨時隨地地運行，來驗證你本次所修改的代碼是否影響到瞭以往的業務邏輯。單元測試是一種保證你所寫的代碼在整個生命周期中都不會齣BUG的防護牆，是具有重要價值的軟件過程製品之一。　　正是因為可以在日後隨時隨地保證代碼的質量，所以我們就可以隨時隨地地進行重構，而不需要害怕自己的修改是否會使以往的代碼齣現BuG。畢竟大部分情況下我們都是在維護一個大型的係統，大型係統的生命周期很漫長，中間會有新功能的添加和舊功能的重構，所以單元測試是非常需要的，應該引起重視。如果沒有單元測試，很難保證代碼在一兩年之後還是清晰的，那就百談不蔔“價值”二字瞭。　　……