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

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

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

通過上面的挫敗,Unity誕生了,企業庫4.0小組,將依賴註入應用程序(已知的Unity最原始的版本)放到了產品列表裏面,我們對於Unity這個項目的目標很簡單,首先，向我們的社區介紹並推廣依賴註入的概念沒有障礙的通過大量底層實現細節。第二，有一個核心的容器，有一個易於使用的API，我們,微軟的其他團隊，或者任何組織對使用可用的開放源碼感到不舒服的人項目（不管出於什麽原因）都可以使用。第三，有各種各樣的可擴展性機制任何人都可以添加功能，而不需要打開核心代碼。

在我的觀點看來,Unity在上面的目標都取得了成功.我對我們對於.Net社區所產生的影響感到驕傲.Unity很快的成為了.Net生態系統中最受歡迎的DI容器.更重要的是,DI不再是"專家技術",而是主流的一部分,甚至是微軟自家的框架(ASP. NET MVC and WebAPI)均來自DI的支持.你得知道,一個概念(依賴註入)變成一個核心觀點,Unity發揮了很大的作用.

1、動機

當您設計和開發軟件系統時，有許多需求需要考慮到。一些是具體的系統問題，一些是通用的問題。您可以將一些需求分類為功能性需求，以及一些非功能性需求。對於每個不同的系統，需求將會有所不同。下面列出的需求是常見的需求，特別是對於業務線的需求（LOB）具有相對較長的預期壽命的軟件系統。它們不一定都是重要的

Unity系列之簡介