微软Enterprise Library 4.0将支持依赖注入

下一个微软Enterprise Library的版本——V4——将预置支持依赖注入。依赖注入将通过容器以独立或作为库的一部分来提供。

特别值得一提的是，下一个Enterprise Library的版本号原本应该是v3.5，现在已将其改为v4.0，这是为了适应库中大量核心变化的需要。微软模式与实践组的产品经理Grigori Melnik对版本的这一变化给出了他的理由：

对于Enterprise Library版本的变化，最初，我们只是打算做一些小的增强和修改。DIAB原本是我们的产品储备中的另一个独立项目，基于最近模式与实践组高级客户的反馈、与Enterprise Library支持者的来往信件、来自模式与实践组和CodePlex上其它团队的评价以及人们建设性的博客记录和建议等，我们认为现在就是推出依赖注入的合适时机，于是我们就将它加入到即将发布的Enterprise Library中，但这已不再是一个小变化，所以，我们决定将其版本号变更为v4。

那么，什么是依赖注入呢？Wikipedia上有这样的解释：

依赖注入(DI)是一种编程技术，有时也被（不正确地）称为 控制反转（或IoC）。其实，从技术角度来说，依赖注入特指对一种特定IoC形式的有限范围实现。

依赖注入是指一个类的实现部分上是由另一个类来执行的情况，这个类就是注射类。某些时候，它们是注射类的多个不同变种（或是其子类）。主类抽象出所有实现所需的通用代码，并在需要特定行为的地方委托给注射类。

控制反转是程序放弃对自己可执行代码的控制权，而只是通过简单地应答请求来执行自己的一种方式（通常是以事件的形式）。同样地，使用依赖注入的类也是放弃了自己部分实现的控制权，让注射类来控制它们的。

依赖注入不是什么新技术，但最近却逐渐流行开来，这里有一篇ThoughtWorks的Martin Fowler写的文章对它进行了很好的介绍。

微软展示了通过向Enterprise Library中增加依赖注入，以更好地利用模块化设计的重要性：

内聚组件式模块化设计的好处现在已经获得了普遍的认可，它可以让组件与软件系统的其它部分只产生少许或完全没有耦合。依赖注入就是彻底解决耦合和减轻组件依赖的一种机制。轻量级依赖注入容器有助于将组件装配（组件也可能来自不同的项目）到一个运行时内聚的应用中，同时促进代码的重用。

微软很早就开始在它们的应用程序中加入合成的模块化设计：

在模块化设计中实现对依赖注入的支持，其价值早已被微软模式与实践部门认识到，并已采用很久了。最早的时候，在Composite UI Application Block(CAB)中实现了它，后来就是Enterprise Library v2（2006年的早些时候），ObjectBuilder的管道允许在运行时决定对象该如何被创建。现在，Enterprise Library的配置系统就是一个基于ObjectBuilder创建的DI容器。

4.0版的Enterprise Library将包括很多新的设计和重构。

在即将发布的EntLib v4版中，我们计划提供支持依赖注入的容器（扁平和层次化的），这些容器将与EntLib v4一起被独立打包。此外，为了展示现实世界中的项目该如何有效使用依赖注入，我们打算重构一个EntLib块，抽像掉其中的配置代码（配置器）。我们还将创建一个EntLib的Facade，以将所需的独立配置器注入其中。客户端可以通过Facade请求服务，DI容器将处理这些请求，并让服务所需的所有对象运行起来。这不仅让设计变得更简洁，同时也让产品更易于使用和配置，而做到这一切，你所需要的只是应用这些程序块。

一些现存的.NET应用框架早已支持依赖注入，而且可以与新的应用程序协同工作，比如：

• Castle Windsor
• StructureMap
• Spring.NET
• Ninject

使用这些容器的组织可以在他们已有的基础结构中应用新的Enterprise Library。任何一个使用现有版本Enerprise Library的人，都可以在不破坏已有代码的情况下升级到新的版本。

更多关于微软Enterprise Library的信息，可以从微软模式与实践部门的网站上获取，不过，现在还没有公布这个库的4.0版本的发布日期。

查看英文原文：Microsoft Enterprise Library 4.0 will get a dose of Dependency Injection