微软 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