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 ienumerablegettenantnames()
}public
class
managementcontroller
public
actionresult index()
;return
this
.view(model);
}public actionresult detail(string
tenant)
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物件,

Unity學習系列一簡介

Unity學習系列一簡介

Unity學習系列一簡介

Docker學習系列（一）Docker簡介

相關推薦