模式和實務: 您可以依賴典範與實例

發行項
10/27/2016

本文章是由機器翻譯。

模式和實務

您可以依賴典範與實例

Alex Homer

內容

模式和實務
指導的 Hand
之後，使用抽象
在 Microsoft 的相依性的一個 Brief 歷程記錄
擴充您自己
摘要

撰寫電腦程式碼用來是非常困難。當我開始更多年前比我記得，唯一的方法如果要讓程式在超過 desultory 耙梳就是撰寫使用機器碼執行處理程式設計家用電腦。即使是簡單的文字處理公用程式可能需要數週，以建立您地規劃變數的記憶體配置、撰寫常式來執行簡單的工作，例如繪圖的字元，在螢幕和解碼的鍵盤上輸入，和的組譯工具中輸入每個個別的處理器指示。

現在的比較，建立功能強大的程式碼很容易。我們要的授與，豐富的工具、高階語言，執行階段的架構、程式碼的程式庫和作業系統的服務，使其可以快速且有效地建置應用程式。不過，時建立程式碼變得更容易，尚未建立應用程式的工作。我們預期更比以前我們現代化的應用程式中。他們必須透過網路，進行通訊與其他應用程式和服務互動，也會公開高度互動和回應使用者介面，並支援多媒體和圖形。而且的不用說必須是強大、安全性、可靠，和管理。

事實上，它會是幾乎不可能符合要求我們現代化的應用程式沒有繼續的成長和發展的程式設計語言、作業系統、平台服務和架構的需求。大量增加這些應用程式的複雜性也有強制我們發現簡化] 和 [組織程式碼的方法。這些的年來許多經過嘗試和測試的程式設計和設計技術有進化，例如 componentization，物件-方向和 — 最近 — 服務方向。

模式和實務

雖然改良工具和架構，讓它更快速地撰寫程式碼更容易和現代化的語言和程式設計的樣式，讓您更容易撰寫更好的程式碼，我們透過前 10 到 15 年中建立應用程式的能力有大部分的影響，一個區域已經在發展] 和 [增加的接受的軟體設計模式。

設計模式會說明常見的問題重複發生，應用程式設計和開發，提供處理這些問題的技術。模式也會描述目前的業界練習解決架構性問題的並處理設計的複雜性要求的應用程式。程式碼] 和 [方案項目的排列方式是軟體設計的核心今天，並模式提供我們簡化和組織這些項目方法 — 提供最佳的機會，以最佳化效能、彈性和可維護性的應用程式。

地面-中斷錄四 Erich Gamma、 Richard 盔 Ralph Johnson 和 John M 的「俱樂部的發行。Vlissides，設計模式：項目的可重複使用物件導向軟體 (Addison-Wesley，1996 年)，記錄的基本設計模式，我們會授與目前的許多可用來開發人員和設計工具的設計模式的數目增長 phenomenal 速度。幾乎每個層面的軟體建立有相關的設計和實作的模式，而只會記錄所有已將成為一不可能的工作。而，設計人員和開發人員通常到 specialties 片段中，，學習模式最適合自己的專業知識的區域。

指導的 Hand

2002，Microsoft Corporation 在模式和實務群組發佈應用程式架構 for.NET：設計應用程式和 Services Guide 》將一起的基本設計指引和專家建議，以協助建置 Microsoft.NET Framework 應用程式架構設計人員。不過，技術所變更的一段時間，和設計和開發指南》中所述的基本原則同樣有效今天，原始本指南未涵蓋一些.NET Framework 的新功能或解決應用程式的新的型別所產生的設計問題時。

過去的數個月廣泛的業界專家和主題專家，內和 Microsoft，之外的小組已建立一個新的版本，本指南提供全面性簡介架構] 和 [設計解決方案，在 Microsoft.NET Framework 上的共同作業。Microsoft 應用程式架構指南》 (第二版) 會描述高層級的架構原則和模式以及目前的想法的可接受的設計和開發作法。它也包含將特定類型的應用程式，套用這些因素的指引，並它會提供許多的平台服務和程式碼程式庫可以輕鬆實作的廣泛概觀]。

不用說到借用常用的片語，軟體和系統架構是，徹底實行的存留在的宇宙，所有問題。沒有單一的出版物可以回答每個可能的問題，或希望能提供完全的全面性的涵蓋範圍的每個可能的案例。不過，新節目表目標是提供的資訊，您需要，是否您只啟動出 designing.NET Framework 架構的應用程式移至.NET Framework 中，從其他的平台達成架構設計人員尋求特定資訊和建議，式經驗豐富的設計工具]，或只是有興趣進一步瞭解各種案例和.NET Framework 所提供的機會。

之後，使用抽象

若要說明產業作法，指南》會列出一般設計的應用程式幾乎任何類型時，您應該套用的原則。這些原則，包括維護區隔使用抽象實作鬆散的連結層之間元件，實作服務位置功能，] 及 [管理 crosscutting 考量，例如記錄] 和 [安全性的問題。雖然這似乎是令人滿意，但不相關的目標一項技術可以協助您輕鬆地套用數個設計原則。相依性的反向原則意味著分離透過抽象 (而非具象實作的考量。方面的設計的模式您可以達成這套用反向的控制項 (IoC) 模式及其相關的模式相依性資料隱碼攻擊 (DI)。

在理論上就夠簡單的。您不需指定在設計階段實際具象型別，每個類別或元件將用來執行某些活動或處理序，您排列這些類別的元件，從您先前使用型別所設定的容器中擷取適當物件對應並註冊型別。例如，簡單應用程式，在 [圖 1 ] 所示，您的資料存取元件可能會要求記錄元件的服務。當您有正確抽象化您的 crosscutting 程式碼，從特定的工作和應用程式特定的程式碼，您可能需要多個記錄的元件，可供選擇。可能是其中一個專為使用偵錯應用程式另一個用於您自己的網路) 上，在內部執行應用程式時，使用時而且第三個最適合利用監視環境例如 Microsoft System Center 的企業層級系統中執行。

[圖 1 的簡化分層和記錄元件在其他的 A 簡單應用程式

即使可能是您有多個資料存取元件，每個設計用於在特定環境中，或與不同的型別的資料存放區的大小寫。因此，您的商務層將會需要選擇適當的資料層元件，根據目前的部署或執行階段環境。以類似的方式您必須在您的應用程式使用重複地，例如，電子郵件訊息傳送服務」或「資料轉換服務的服務。相依性資料隱碼，可做為服務位置的設備，以協助您在執行階段，擷取的服務執行個體 (新的執行個體或現有的執行個體) 的應用程式。

每一個這些範例的其他，有效地說明應用程式的一部分的相依性]，並解決不緊密 BackgroundWorker 物件，這些相依性為目標的相依性的反向原則。

在 Microsoft 的相依性的一個 Brief 歷程記錄

雖然相依性的原則很長的時間已經解決，功能，可協助開發人員在執行於 Microsoft 平台應用程式中實作會是反向的相對最新的。事實上，有是說故事的聲望已經開發人員在 Java 世界造訪在 Microsoft 的校園時 remarked 一般的信念已經沒有人在 Microsoft 無法拼出相依性插入。同時也就是，不一定的末世的神獸它是如此工具，可協助開發人員實作許多常見的模式未在大部分的公司部分優先順序。

不過，Microsoft 典範與實例小組突出到我們的公司內但在主要的產品開發小組和內文區塊外的唯一的位置。p & p，所示的「證實的作法可預測的結果」我們標語的目標，是以提供開發人員指南、工具、程式庫、架構及其他設備，幫助他們設計和建置更好的應用程式在 Microsoft 平台上的無數。在快速快速我們MSDN 上的首頁將會說明各種我們所提供的資產。

在這些資產是數個產品，讓使用相依性插入模式包括 Enterprise Library、複合應用程式的架構和軟體工廠。在這些資產的開發，特別原始的複合應用程式區塊 (CAB) 它成為清除可重複使用和高度的可設定的相依性資料隱碼機制所需)，因此小組建置物件產生器的原始版本。

物件產生器是幾乎完全設定的而且現在用於各式各樣的產品 p & p 整個和 Microsoft 內其他地方。不過，很很難使用。它需要好的許多參數，複雜的物件，而且它會公開事件，您必須在要套用您所需要的組態處理這些事件的範圍]。初始會嘗試為封包專案的一部分很快就會顯示這要的 uphill 工作文件產生器的物件。另外，物件產生器已而超過相依性資料隱碼攻擊，容器，並且似乎 overkill 中一般需求實作 DI) 和 IoC) 模式的方面。

Enterprise Library 4.0 的開發，期間物件產生器已更新-不簡化它，而是，使其更快且更有效率。它也已微調在第一個主要的相依性資料隱碼機制，從 Microsoft 的目標是跡象在開發人員若要實作 DI) 和 IoC 模式中使用。物件的產生器會是 Unity，輕量型、可擴充的相依性的資料隱碼容器支援建構函式資料隱碼攻擊、屬性資料隱碼攻擊和方法呼叫資料隱碼，基礎。

unity 會提供簡化的物件建立，特別是針對階層式物件的結構和相依性的功能; 抽象的需求在執行階段或透過組態的 crosscutting 考量，簡化的管理，並增加彈性 deferring 至容器元件組態。它會有一個服務位置功能，並允許儲存或快取容器的用戶端 — 甚至在 ASP.NET Web 應用程式中。

在早期的 2008 中第一個版本 Unity 發行，它有做為實作相依性的反向的預設機制許多 p & p 資產中找首頁。unity 也有持續發展，其餘的回溯相容時，；您可以使用它，來啟用企業的媒體櫃，中的功能，以及使用它，以做為獨立 DI 容器]。在最新的版本中，它提供實作的執行個體中，並攔截 (透過外掛程式的副檔名) 的型別允許方面導向程式設計技術 (例如原則資料隱碼的實作的功能。

unity 也已繁衍其他 DI 容器實作，針對特定的工作，及諸如此設計非常輕量型實作的需求使用於行動裝置] 及 [智慧型電話]。同時，計劃未來的發展，在 Unity 和 Enterprise Library 競技場會包含要同時提供其他副檔名的 Unity 啟用新的功能開啟其他協力廠商] 容器機制，Enterprise Library 的功能。套用相依性的反向

離開這個歷程記錄的困擾，並回到假設的應用程式如何可以套用以達成「目標相依性反向原則，前述，有效地分離問題、抽象和鬆散連結的嗎？答案是與適當的型別中設定一個相依性資料隱碼容器中的，例如 Unity，和對應的型別，並讓應用程式擷取，並在執行階段插入適當的物件的執行個體。[圖 2] 會示範您，如何使用 Unity 應用程式區塊來實作此容器。在這種情況下，您填入容器具有資料元件和記錄的元件的介面定義與想要在應用程式來使用這些介面的具體實作特定的型別對應。

[圖 2] 的 相依性資料隱碼，可以選取適當的元件在執行階段，根據設定的容器 。

執行階段商業層會查詢容器以擷取正確的資料層元件根據其目前的對應的執行個體。資料層，然後將查詢容器以取得適當的記錄元件根據儲存的介面型別的對應的執行個體。為替代的資料和記錄的元件，可能會繼承自個別的基底類別] 及 [登錄在容器中的可以對應這些基底型別和繼承的具象型別。

這個容器導向方法解析型別和執行個體，表示程式開發人員是隨意變更實作資料和記錄的元件，只要這些實作會提供所需的功能，並公開 (例如，由對應的介面的實作或繼承自對應的基底類別) 的適當介面。在執行階段使用容器 (Container) 的註冊型別、型別的對應或物件的現有執行個體的方法，可能在程式碼中設定容器的組態。或者，您可以藉由從組態來源或檔案，例如 web.config 或 App.config 檔案中載入，登錄填入容器。

要註冊多個型別的執行個體時您可以使用名稱，定義每一個，並藉由指定名稱，然後解決不同型別。登錄也可以指定物件，並使其易於達成服務位置樣式功能以單一或例如每個執行緒一特定輩子註冊服務物件存留期。下列的 T: System.Web.UI.MobileControls.Adapters.XhtmlAdapters.範例將顯示您的容器上註冊型別對應的一些範例：

C#
// Register a mapping for the CustomerService class to the IMyService interface. 
myContainer.RegisterType<IMyService, CustomerService>();

// Register the same mapping using a mapping name. 
myContainer.RegisterType<IMyService, CustomerService>("Data");

// Register the first mapping, but as a singleton. 
myContainer.RegisterType<IMyService, CustomerService>(
                         new ContainerControlledLifetimeManager());

注意：在程式碼範例會參考類別和使用類別名稱的型別。您可以在組態檔中別名類別的完整型別名名稱可簡化容器登錄，當您使用的組態檔時使用型別的別名定義。

若要擷取物件的執行個體，您只要查詢容器藉由指定型別、介面型別，或基底類別型別 (和的名稱)，如果您註冊型別使用的名稱下, 一個範例中所示。如果它已註冊並建立或傳回適當的物件的執行個體，容器會解析該的型別。如果沒有登錄，容器會只會建立該型別的新執行個體，並回送它。為什麼會您解決透過容器項目時沒有註冊的型別？其概念是要利用其他] 和 [非常有用的功能，Unity 及許多其他 DI 容器機制，提供 — 能夠插入使用建構函式、屬性 setter 和方法呼叫資料隱碼物件。

C#
// Retrieve an instance of the mapped IMyService concrete class. 
IMyService result = myContainer.Resolve<IMyService>();
// Retrieve an instance by specifying the mapping name. 
IMyService result = myContainer.Resolve<IMyService>("Data");

例如此之外，當您建立透過容器物件的執行個體時，Unity 會檢查建構函式，並會自動將適當的型別的執行個體插入建構函式參數。回到我們先前的簡單應用程式範例，資料存取元件可能具有的建構函式可接受記錄元件做為參數參考。如果這個參數的型別會是介面或基底類別記錄與容器已註冊的元件，Unity 便會解析對應的型別、建立的執行個體，以及將它傳遞至資料的元件 (如 [圖 3 ] 所示) 的建構函式 (Constructor。您會執行註冊以外任何對應。

[圖 3 至參數的建構函式中插入物件

C#
// In main or startup code:
// Register a mapping for a logging component to the ILogger interface.
// Alternatively, you can specify this mapping in a configuration file. 
myContainer.RegisterType<ILogger, MyLogger>();

...

// In data access component:
// Variable to hold reference to logger.
private ILogger _logger = null;

// Class constructor. Unity will populate the ILogger type parameter.
public DataAccessRoutines(ILogger myLogger)
{
  // store reference to logger
  _logger = myLogger;
  _logger.WriteToLog("Instantiated DataAccessRoutines component");
}

這表示您可以變更之實際的具象型別的應用程式使用只要變更組態容器 (Container) 的 — 是在設計階段，在時間藉由編輯的組態 (或) 動態基礎上執行一些值，從環境中收集您的程式碼，並使用建立或更新在容器中的對應。您可以偵錯記錄元件所需要的外掛程式，或插入新「超級快速「記錄元件，當您找到舊的速度太慢。同時，系統管理員可以更新組態，需要監視、管理，及調整應用程式的行為，在執行階段花色變更環境和操作的問題。

同樣地，如果您兩個物件之間相依性例如檢視上的主持人的相依性當您實作模型-檢視-主持人 (MVP) 模式，您可以使用相依性資料隱碼攻擊以放寬這些類別之間的連結。只要定義為主持人型別的檢視類別的屬性或基底類別的型別，並標示具有相依性屬性，屬性，如所示下一個範例中：

C#
// Variable to hold reference to controller.
private IPresenter _presenter;

// Property that exposes the presenter in the view class. Unity will inject 
// this automatically because it carries the Dependency attribute.
 [Dependency]
public IPresenter MyViewPresenter
{
  get { return _presenter; }
  set { _presenter = value; }
}

注意：屬性 (Attribute) 會是最快方式指定要插入屬性。如果您不希望使用屬性 (以避免連接您的類別至的容器) 您可以改用組態檔或 Unity API 來指定哪些屬性應該插入。

當您透過容器解析它建立檢視時 Unity 會偵測相依性屬性，自動解析適當具體的主持人] 類別中的執行個體並將它設為檢視類別的該屬性的值。[快速入門的範例，隨附於 Unity 會示範在 Windows Form 應用程式中的，這個方法。它實際上會解析透過會使建立和填入數個相依性，整個應用程式使用建構函式和屬性 setter 資料隱碼攻擊的 Unity 容器應用程式的主要表單。

擴充您自己

unity 提供 DI-相關的功能豐富但有一定是額外要達成的項目。Unity 的挑戰是使其泛用，以滿足需求，最大數目時的可擴充，讓您可以調整它自己的特定需求。這是藉由使用可讓您執行幾乎任何方面的管理物件的建立和擷取的容器擴充來達成。

例如，隨附 Unity [快速啟動會示範實作一個簡單的屬性 (Attribute) 導向 Publish\Subscribe 機制.容器副檔名。Unity 會建立物件的執行個體，它就會連事件處理常式為它們根據屬性在類別檔案中]。它會建立，或擷取每個型別，透過容器可協助您正在偵錯複雜的應用程式時，另一個範例會產生詳細的記錄資訊。

這個大的彈性是有關，因為 Unity 可讓您與產生器的機制，透過您的容器延伸基礎物件互動。喔，您可以說，但是物件產生器很難使用及不完整記錄。事實上，Unity 文件會包含物件產生器的方式您和它互動從容器副為的相關資訊，並快速入門範例提供足夠的範例程式碼，您可以使用和修改。

摘要

有許多應用程式架構及設計檢視。在 ISO / IEC 標準 42010:2007 / IEEE 1471 建議的軟體需要大量的系統的結構描述的實務作法」描述軟體架構，為「系統在其元件，彼此以及在的環境和指導，其設計和發展原則其關聯性中嵌入的主要組織」。不過，企業應用程式架構 (Addison-Wesley，2002) 的他錄模式，Martin Fowler 指出，「...in 結束，架構由下到任何重要的東西是，」這是一個更簡單方式擷取軟體架構的精神！

Microsoft 應用程式架構指南》 (第二版) 都將會協助您瞭解哪些重要的東西是，如此您可以建置更好，高品質應用程式更快速地更有效率。您已經瞭解本文一個特定的區域中 — 並在相依性資料隱碼的優點和控制項模式的反向 — 可以協助您達成許多升級，本指南的設計目標。這包括區隔問題，實作層級、服務的位置和 crosscutting 考量改善管理功能的實作之間的鬆散連結的抽象概念的使用。

Alex Homer 都是使用 Microsoft 典範 & 實例團隊在文件工程師。關於生命週期、技術和世界他隨機 ravings 通常可以在找到https://blogs.msdn.com/alexhomer/ .

其他資源