一、简介
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包管理器在项目中安装统一程序集。
