Unity學習系列一簡介

一、簡介

Unity的目標是為了提升"依賴注入"的思想,去建立更加松耦合的系統.patterns & practices 小組在那個時候實現DI的方式和我們現在認為的DI有所不同,DI不是單一的可重復使用的容器,而是應該專門用於正在使用它的系統.

我們使用一個叫做ObjectBuilder的類庫(一個用於創建DI容器的框架),所以,理論上我們可以為我們的每一個項目創建一個容器,這正是我們想要做的.理想很美好,但是它工作的並不是很好,ObjectBuilder是一個高度解耦、抽象的,使用它必須手動組裝它,再加上缺乏文檔，花了很多時間了解需要去哪里,以及如何將其整合到有用的東西中去,而這些時間花在了編寫、調試和優化DI容器上，而不是在實際的項目需求上工作上。有趣的是當有人想要引用CAB（它使用了一個基於一個版本的DI容器ObjectBuilder）和企業圖書館（基於不同版本的ObjectBuilder）在同一個項目中。集成將會變得非常困難。光光在同一個項目中處理兩個不同的版本ObjectBuilder，也是一個不小的挑戰。還有一次性的容器導致了一次性的可擴展性和集成接口：在企業庫中沒有用的在CAB中也沒有用。

當我們在Web客戶端軟件工廠項目的末尾又花了一個星期的時間修復了CWAB中的一堆bug:(這些bug和在CAB中的非常相似),所以為什么不用一個容器實現,代替重復的實現一個又一個的容器。

 

由此產生的挫折感使人們團結起來。EnterpriseLibrary 4.0團隊將依賴注入應用程序塊(最初稱為Unity)放在產品待辦事項上。,我們對於Unity這個項目的目標很簡單,。首先，向我們的社區引入並推廣依賴注入的概念，不受許多低級別實現細節的限制。第二，有一個具有易於使用API的核心容器，我們、Microsoft的其他團隊或任何組織不願意使用可用的開源項目的人(無論出於什么原因)都可以使用這些API。第三，有多種擴展機制，這樣任何人都可以添加新功能，而不必打開核心代碼。

 

在我看來，Unity在所有這些目標上都取得了成功。我對我們如何影響.NET開發人員社區感到特別自豪。Unity很快成為.NET生態系統中最常用的DI容器之一.更重要的是,DI不再是"專家技術",而是主流的一部分,甚至是微軟自家的框架(ASP. NET MVC and WebAPI)均來自DI的支持.你得知道,一個概念(依賴注入)變成一個核心觀點,Unity發揮了很大的作用.

 

二、使用Unity的條件

1、支持的架構:x86和x64.·

2、操作系統：Windows 8、Windows 7、Windows Server 2008 R2、Windows Server 2012。·

3、支持的.NET框架：Microsoft.NET Framework 4.5、.NET for Windows Store應用程序(以前稱為WinRT)。·

4、支持的開發環境：MicrosoftVisualStudio 2012、專業版、終極版或速成版。

可以使用VisualStudio中的NuGet包管理器在項目中安裝統一程序集。

 

三、介紹

1、動機(Motivations)

當您設計和開發軟件系統時，有許多需求需要考慮到。一些是具體的系統問題，一些是通用的問題。您可以將一些需求分類為功能性需求，以及一些非功能性需求。對於每個不同的系統，需求將會有所不同。下面列出的需求是常見的需求，特別是對於lineof-business（LOB）具有相對較長的預期壽命的軟件系統。當然它們並不一定對你所開發的每一個系統都很重要,但是你可以確定其中的一些將會出現在你所從事的許多項目的需求列表中。

 

2、可維護性(Maintainability)
當系統變得更越來越大，預期壽命也變得越來越長,維護這些系統變得越來越困難。隨着開發這個系統的項目成員的調整,就沒還是原班人馬,但是他們可能忘記了系統上的一些細節.文檔可能已經過時了，甚至丟失。同時,企業可能要求迅速采取行動,一些緊迫的新業務需要。 可維護性是軟件系統的一個重要的特性,那決定了你如何高效並且輕松得去更新和維護他.如果你發現了必須修復的bug(換句話說,執行常規的維護保養),那這個時候必須去更新一個系統,如果操作環境變化,要求你必須對系統進行改進,或者你需要加入一個新的特性去滿足業務需求(perfective maintenance[改善型維護]).可維護的系統提高了系統的靈活性而且減少了系統的開銷.因此，您應該將可維護性作為您的設計目標之一,以及可靠性、安全性和可伸縮性等優點。

 

3、可測試性(Testability)

一個可測試系統可以使你有效地測試各個部分的系統。設計和編寫有效的測試和設計和編寫可測試的應用程序代碼一樣具有挑戰性.特別是當系統特別大和復雜的時候.測試驅動開發(TDD),在編寫任何實現新代碼之前，需要編寫單元測試。這種設計技術的特點和目的是提高你的應用程序質量。這種設計技術也有助於擴大你的單位測試的覆蓋范圍。減少回歸測試的可能性.使重構變得盡可能的簡單.然而,作為測試過程的一部分，您還應該包含其他類型的測試。例如驗收測試、集成測試、性能測試和壓力測試。由於在現實環境中進行測試,運行測試需要花費金錢和時間。例如，對於某些類型的測試,並且測試的載體在雲上,所以您需要將應用程序部署到雲環境並在雲中運行測試。由於部署應用程序需要花費時間的原因，在雲中運行所有的測試是不切實際的。甚至是本地模擬器,在這種情況下，您可以決定使用測試雙打(簡單的存根或可驗證的模擬)。用測試實現替換雲環境中的實際組件。為了使您能夠在隔離期間運行您的單元測試套件。在標准的TDD開發周期期間.可測試性應該是您的系統的另一個設計目標。可維護性和敏捷性:可測試的系統通常更易於維護。亦然。

 

4、靈活性和可擴展性(Flexibility and Extensibility)

一個好的企業級應用活性和可擴展性也是必備的.考慮到需求經常變化,無論是在應用程序的開發過程中還是在生產中運行之后，您都應該嘗試將應用程序設計成靈活的應用程序，使其能夠以不同的方式和可擴展的方式工作，從而可以添加新的功能。例如,您可能需要將您的應用程序從部署到本地轉換成部署到雲端.

 

 

5、延遲綁定(Late Binding)

在某些應用場景之下,如果你需要替換部分系統不編譯,那么延遲綁定(Late Binding)非常有用.例如,你的應用系統可能需要支持多種關系型數據庫,對於每種數據庫類型,你都需要一個單獨的模塊來支持.你可以使用申明式的配置告訴應用程序在運行時加載對應的模塊.另一個延遲綁定(Late Binding)可能有用的場景是，使系統的用戶能夠通過插件提供他們自己的自定義。您可以通過使用配置設置或約定指示系統使用特定的自定義，其中系統掃描文件系統上的特定位置以供模塊使用。

 

6、平行開發(Parallel Development)

當你在開發大規模(甚至是中小型)系統,讓整個開發團隊同時在相同的特性或組件上工作是不實際的.事實上,你將不同的特性和組件分配給要並行處理的小組。雖然這種方法使您能夠縮短項目的總體工期。它確實帶來了額外的復雜性.您需要管理多個組，並確保可以集成由不同組開發的應用程序的各個部分，以便正確地一起工作。

 

7、橫切關注點(Crosscutting Concerns)

      企業級應用程序經常需要處理一些橫切關注點,例如驗證、異常處理、日志.您可能需要在應用程序的許多不同領域中使用這些特性，並且希望以一種標准、一致的方式來實現它們，以提高系統的可維護性。理想情況下,您需要一種機制,使您能夠在設計時或者運行時高效透明地向對象添加行為.而不用對現有類進行修改.橫切關注點請參考 Aop學習筆記系列一

 

8、松耦合(Loose Coupling)

您可以通過確保您的設計在一個應用程序中松散地將組成應用程序的許多部分連接在一起，來滿足前面章節中列出的許多需求。松耦合,相對於緊耦合意味着減少構成系統的組件之間的依賴關系.這使得在系統的一個區域中進行更改變得更容易和更安全，因為系統的每個部分在很大程度上都是獨立的.

 

9、一個簡單的例子

下面的示例說明了ManagementController類直接依賴TenantStore類的緊耦合。這些類可能在不同的VisualStudio項目中。在本指南中,ManagementController和TenantStore類以各種形式使用

    public class TenantStore
    {

        public Tenant GetTenant(string tenant)
        {

        }
        public IEnumerable<string> GetTenantNames()
        {

        }
    }

    public class ManagementController
    {
        private readonly TenantStore tenantStore;
        public ManagementController()
        {
            tenantStore = new TenantStore();
        }
        public ActionResult Index()
        {
            var model = new TenantPageViewData<IEnumerable<string>>
                (this.tenantStore.GetTenantNames())
                {
                    Title = "Subscribers"
                };
            return this.View(model);
        }
        public ActionResult Detail(string tenant)
        {
            var contentModel = this.tenantStore.GetTenant(tenant);
            var model = new TenantPageViewData<Tenant>(contentModel)
            {
                Title = string.Format("{0} details", contentModel.Name)
            };
            return this.View(model);
        }
    }

       在本系列中,ManagementController和TenantStore類以各種形式使用,盡管ManagementController是一個Asp.Net Mvc控制器.您不需要了解MVC來跟進。但是，這些示例看起來像在現實世界系統中遇到的類，特別是第3章中的示例。

在這個例子中TenantStore類實現了一個倉儲，該倉儲處理對基礎數據存儲(例如關系數據庫)的訪問,ManagementController是一個MVC控制器,它從倉儲請求數據,注意，ManagementController類必須先實例化TenantStore對象，或者在調用GetTenant和GetTenantNames方法之前，從其他地方獲取TenantStore店對象的引用。ManagementController類依賴於特定的具體TenantStore類。

        如果您在本章開始時參考了企業應用程序常見的理想需求列表，您可以評估前面代碼示例中概述的方法如何幫助您滿足它們。雖然這個簡單的示例只顯示TenantStore類的單個客戶端類，實際上，應用程序中可能有許多使用TenantStore類的客戶端類。如果假設每個客戶端類負責在運行時實例化或定位TenantStore對象,