[EntLib]微软企业库5.0 学习之路——扩展学习篇、库中的依赖关系注入(重构 Microsoft Enterprise Library)[转]

这篇文章是我在patterns & practices看到的一篇有关EntLib5.0的文章,主要介绍了EntLib5.0的这次的架构变化由来,觉得很不错,大家可以看一下!

 

在过去几年中,依赖关系注入 (DI) 模式在 .NET 开发人员社区一直受到关注。长时间以来,优秀的博客作者们讨论着 DI 的优点。MSDN 杂志 针对这一主题发表了多篇文章。.NET 4.0 将发布某种类似 DI 的功能,并计划以后将其发展为完整的 DI 系统。

阅读有关 DI 的博客文章时,我注意到,这一主题有一个很小却很重要的倾向。作者们谈论的是如何在整个应用程序环境中使用 DI。但如何编写使用 DI 的库或框架呢?关注重点的变化,对模式的使用有何影响?这是几个月前我们研究 Enterprise Library 5.0 的体系结构时首先遇到的问题。

背景

Microsoft Enterprise Library (Entlib) 是 Microsoft 模式与实施方案组开发的著名版本。迄今为止,其下载次数已超过两百万。可以想到的单位 — 从金融机构、政府机关到餐厅和医疗设备制造商 — 都在使用它。顾名思义,Entlib 是一种库,可帮助开发人员处理许多企业开发人员都会面临的问题。如果您不熟悉 Entlib,请访问我们的网站 p&p 开发中心,以了解更多信息。

Entlib 在很大程度上由配置驱动。它的大部分代码专用于读取配置,然后基于配置组合对象图。Entlib 对象可能非常复杂。大多数块都包含大量可选功能。此外,还有许多用于支持检测等功能的底层基础结构,它们也需要进行关联。我们不希望用户仅仅为了使用 Entlib 而去手动创建检测提供程序、读取配置,等等,所以将对象的创建封装在了工厂对象和静态外层之后。

Entlib 版本 2 到版本 4 的核心是一个名为“ObjectBuilder”的小型框架。ObjectBuilder 的作者将 ObjectBuilder 描述为“一种用于构建依赖关系注入容器的框架”。Enterprise Library 只是使用 ObjectBuilder 的 p&p 项目之一;其他使用 ObjectBuilder 的 p&p 项目包括 Composite UI Application Block、Smart Client Software Factory 和 Web Client Software Factory。Entlib 特别注重说明的“框架”部分,将一个很大的自定义功能集构建至 ObjectBuilder。读取 Entlib 配置和组合对象图时,需要使用这些自定义功能。在很多情况下,也需要用它们来改进现有 ObjectBuilder 实现的性能。

缺点在于,需要不少时间才能对 ObjectBuilder 本身(设计极为抽象,再加上完全没有文档,ObjectBuilder 的复杂性绝非虚言)和 Entlib 自定义功能都有所了解。因此,如果要编写与 Entlib 的对象创建策略有关的自定义块,一开始就需要进行大量学习,常常令人感觉困难重重。

此外,在 Entlib 4.0 中,我们发布了 Unity 依赖关系注入容器,这进一步增加了复杂性。DI 具有很多优点,我们希望确保为无法从众多优秀开放源代码容器中选用一种(无论什么原因)的客户提供一个很好的选择 — Microsoft 的 DI。当然,我们也希望在使用 Unity 时轻松实现 Entlib 对象的运行。在 Entlib 4.0 中,Unity 集成与现有 ObjectBuilder 基础结构一道,成为了并行对象创建系统。现在,块编写者不仅需要了解 ObjectBuilder 和 Entlib 扩展,还需要了解 Unity 内部机制,以及其中的部分 Entlib 扩展。这不是朝正确的方向前进。

致力于简化

2009 年 4 月,我们开始 Entlib 5.0 的开发。这一版本的主要目的是“以简化取胜”。这不仅包括为最终用户(调用 Entlib 的开发人员)进行简化,也包括对 Entlib 代码本身进行简化。通过这些改进,我们可以更方便地保持 Entlib 的进一步发展,客户也可以更方便地对它进行了解、自定义和扩展。

我们知道,有些重要方面需要改进,其中之一是对象创建管道。保留两个并行但不同的代码集实现同一功能会后患无穷。必须改变这种情况。

我们制定了以下重构目标:

  • 现有客户端代码不必仅因体系结构更改而更改。可要求重新编译,但不可要求更改源代码(当然,客户端 API 可以因其他 原因进行更改)。可处理内部 API 或可扩展 API。
  • 删除冗余对象创建管道。应只保留一种(而非两种或更多)创建对象的方式。
  • 不使用 DI 的客户不应受在内部使用 DI 的 Entlib 的影响。
  • 确实需要 DI 的客户可以选择所需容器,然后从中获取自己的对象和 Entlib 对象。

无论从单独还是组合的角度来讲,这些目标都意味着要进行大量工作。从表面看,“一个对象创建管道”目标相当简单。我们决定完全删除基于 ObjectBuilder 的系统,在内部采用一个 DI 容器作为对象创建引擎。但是,我们需要考虑“不应更改现有客户端代码”。传统 Entlib API 是一组静态外层和工厂。例如,使用日志记录块来记录一条消息可采用如下方式:

Logger.Write("My Message");

实际上,Logger 外层使用 LogWriter 对象的实例执行实际工作。那么,Logger 外层如何获得 LogWriter?LogWriter 是一个相当复杂的类,具有大量依赖关系,因此,如果采用新建的方式,配置是无法正确关联的。我们认为,在 API 中,Logger 和所有其他静态类需要一个全局容器实例。我们可以仅保留一个全局 Unity 容器,但是,我们需要考虑“客户选择所需容器”。

我们希望 Unity 和 Entlib 组合能实现一流的体验。我们也希望通过其他容器也能实现这种一流体验。尽管 DI 容器的常规功能都一致,但访问这些功能的方式却有很大差异。实际上,许多容器创建者都认为他们的配置 API 是主要竞争优势。因此,我们如何将 Entlib 配置映射到差异很大的容器 API 上?

传统计算机科学解决方案

这是计算机科学领域公认的事实:计算机科学中的所有问题都可以通过添加一个间接层解决。这正是我们解决容器独立问题的方法。我们把这个间接层称为容器配置程序。从本质上说,配置程序的作用是读取 Entlib 的配置,并对容器进行配置以便匹配。

遗憾的是,读取配置本身还不够。Entlib 的配置文件格式很大程度上是以最终用户为中心的。用户配置日志记录类别、异常策略和缓存后备存储。但不说明要完成相应功能实际所需的对象、要向构造函数传递的值以及要设置的属性。另一方面,DI 容器配置的内容则是“将此界面映射到此类型”、“调用此构造函数”和“设置此属性”等。我们需要另一个间接层将块的配置映射到实际所需对象来实现块。另一种方法是,让每一个配置程序(每个容器都需要一个配置程序)都知道每一个块的详细信息。很明显,这不可行;对块代码进行任何更改都将波及所有配置程序。如果有人编写自定义块,会发生什么情况?

我们最后开发了一组名为“TypeRegistration”的对象。各配置节负责生成一个类型注册模型 ,一系列 TypeRegistration 对象。TypeRegistration 的接口如图 1 所示。

图 1 TypeRegistration 类

public class TypeRegistration
    {

        public TypeRegistration(LambdaExpression expression);
        public TypeRegistration(LambdaExpression expression, Type serviceType);

        public Type ImplementationType { get; }
        public NewExpression NewExpressionBody { get; }
        public Type ServiceType { get; private set; }
        public string Name { get; set; }

        public static string DefaultName(Type serviceType);
        public static string DefaultName<TServiceType>();

        public LambdaExpression LambdaExpression { get; private set; }

         public bool IsDefault { get; set; }

         public TypeRegistrationLifetime Lifetime { get; set; }

         public IEnumerable<ParameterValue> ConstructorParameters { get; }

         public IEnumerable<InjectedProperty> InjectedProperties { get; }
    }

该类的内容很多,但基本结构非常简单。该类描述单个类型所需的配置。ServiceType 是用户从容器进行请求的接口,而 ImplementationType 则是实际实现该接口的类型。Name 是注册服务时应使用的名称。生存期可确定单一实例(每次都返回同一实例)或瞬态(每次都创建新的实例)创建行为。其他在此就不一一列举了。我们选择使用 lambda 表达式来创建 TypeRegistration 对象,因为这样可以非常方便地在单一紧凑的范围内指定所有这些信息。以下是从数据访问块创建类型注册的示例:

yield return new TypeRegistration<Database>(
       () => new SqlDatabase(
           ConnectionString,
           Container.Resolved<IDataInstrumentationProvider>(Name)))
       {
           Name = Name,
           Lifetime = TypeRegistrationLifetime.Transient
       };

此类型注册表示“如果请求名为 Name 的数据库,则返回一个新的 SqlDatabase 对象,该对象由 ConnectionString 和 IDataInstrumentationProvider 构造”。此处使用 lambda 的好处在于,在编写块时,可像直接新建对象一样构建这些表达式。编译器将对表达式进行类型检查,这样,我们就不会在无意中调用不存在的构造函数了。若要设置属性,可在 lambda 表达式内使用 C# 对象初始值设定项语法。TypeRegistration 类负责处理检查 lambda、提取构造函数签名、参数、类型等等的详细信息,以免配置程序作者为之操心。

我们用过的一个实用的技巧是调用“Container.Resolved”。该方法实际上不执行任何操作,它的实现如下:

public static T Resolved<T>(string name)
{
     return default(T);
}

为什么要用它?请注意,此 lambda 表达式实际上从不执行。相反,我们是在运行时通过运行表达式的结构提取注册信息。此方法只是一个众所周知的标记。如果将对 Container.Resolved 的调用作为参数,我们解释为“通过容器解析此参数”。我们发现,用表达式树执行高级工作时,此标记方法技术在很多情况下很有用。

最后,配置的容器的配置文件流程如图 2 所示。


图 2 容器配置

此处要说明一下我们的一项设计决策,这非常重要。TypeRegistration 系统现在不是(以后也绝不会成为)任何 DI 容器的通用、全面配置抽象概念。它是应 Enterprise Library 项目之需专门设计的。模式和实施方案组无意将它作为基于代码的指南。尽管基本概念(将配置提取到抽象模型中)普遍适用,此处的特定实现仅适用于 Entlib。

从容器中获取对象

这样,我们就配置了容器。这只完成了一半工作。如何才能从容器中获取对象?在这方面,容器接口各不相同,令人欣慰的是,这种不同没有其配置接口那样大。

很幸运,这时我们不必创造新的抽象概念。受 2008 年夏 Jeremy Miller 发表的博客文章的启发,Microsoft 的模式和实施方案组、MEF 团队和许多不同的 DI 容器的作者们合作,定义了一个最低通用标准,以解决从容器中解析出对象的问题。该标准作为 Common Service Locator 项目发布在 Codeplex 和 MSDN 上。该接口正好满足我们的需要;在 Enterprise Library 中,无论何时需要从容器中获取对象,都可通过该接口进行调用,并与所用的特定容器隔离开。当然,下一个问题是:容器在哪里?

Enterprise Library 没有任何类型的引导需求。使用静态外层时,不需要在任何位置调用初始化函数。首次需要原始库时,可通过提取配置来运行它。我们必须复制此行为,以便在调用时,库已准备就绪可供使用。

我们需要的是众所周知的标准库,以便获取正确配置的容器。实际上,Common Service Locator 库具有以下功能之一:ServiceLocator.Current 静态属性。由于种种原因,我们决定不使用此属性。主要原因是,其他库,甚至应用程序本身都可使用 ServiceLocator.Current。我们需要在首次访问任何 Entlib 项目时,能够对容器进行设置;其他都不重要,比如人们试图弄明白为何其认真构建的容器会消失,或为何 Entlib 在首次调用可以运行,但后来就不行了。第二个原因与接口本身的一个缺陷有关。无法查询该属性,因而不能确定是否已对其进行了设置。这样就很难确定何时设置容器。

因此,我们构建了自己的静态属性:EnterpriseLibraryContainer.Current。在用户代码中也可以设置此属性,但它是 Enterprise Library 的特定部分,因此,减小了与其他库或主应用程序发生冲突的可能性。首次调用静态外层时,应检查 EnterpriseLibraryContainer.Current。如果已设置,则可使用其值。如果未设置,则应创建一个 UnityContainer 对象,用配置程序对其进行配置,并将其设置为 Current 属性的值。

这样,现在就有了三种不同的方式,可访问 Enterprise Library 的功能。如果使用传统 API,一切都会正常运行。在底层,将创建和使用 Unity 容器。如果要在应用程序中使用不同的 DI 容器,不希望进程中有 Unity,但仍使用传统 API,则可以使用配置程序来配置您的容器,将其封装在 IServiceLocator 中,并附于 EnterpriseLibraryContainer.Current 中,这样,外层仍将正常运行。它们现在才在底层使用您所选择的容器。实际上,在主 Entlib 项目中,我们不提供任何容器配置程序(Unity 除外);我们希望,社区将为其他容器实现配置程序。

第二种方法是直接使用 EnterpriseLibraryContainer.Current。可调用 GetInstance<T>() 以获取任何 Enterprise Library 对象,该对象会提供一个配置程序。同样,如果愿意,也可在其后附一个其他容器。

最后一种方法,您可以直接使用所选容器。必须使用配置程序将 Entlib 配置引导到容器中,但如果要使用容器,则需要对其进行设置,这并不是一个新要求。然后,将所需 Entlib 对象作为依赖关系进行注入,即可正常运行。

如何评价我们的工作?

回顾一下我们的目标以及我们的设计是否符合这些目标。

  1. 现有客户端代码不必仅因体系结构更改而更改。可要求重新编译,但不可要求更改源代码(当然,客户端 API 可以因其他 原因进行更改)。可处理内部 API 或可扩展 API。

    符合。原始 API 仍可正常运行。如果您不使用依赖关系注入,则不需要了解也不需要关心您的对象在底层是如何关联的。

  2. 删除冗余对象创建管道。应只保留一种(而非两种或更多)创建对象的方式。

    符合。代码库不再使用 ObjectBuilder 堆栈;现在,一切都通过 TypeRegistration 和配置程序机制进行构建。每个容器都需要一个配置程序。

  3. 不使用 DI 的客户不应受在内部使用 DI 的 Entlib 的影响。

    符合。DI 不会自己出现,除非您希望它出现。

  4. 确实需要 DI 的客户可以选择所需容器,然后从中获取自己的对象和 Entlib 对象。

    符合。您可直接使用所选 DI 容器,也可在静态外层之后使用它。

此外,我们还实现了其他一些优点。简化了 Entlib 代码库。我们从原始实现中删除了大约 200 个类。添加类型注册进行重构之后,一共减少了大约 80 个类。此外,添加的类比删除的类更简单,明显提高了整体结构的一致性,减少了移动部件或特殊情况。

另一个优势是,重构的版本比原始版本更快一些,初步的非正式评估显示,性能提高了 10%。这些数字说明我们的工作是有效的。原始代码中的复杂性大多源于针对 ObjectBuilder 的缓慢实现需要进行一系列性能优化。大多数 DI 容器针对其常规性能进行了大量工作。通过在容器之上重建 Entlib,可以利用这些性能优化工作,从而不必自己完成大量这类工作。随着 Unity 和其他容器向前发展和优化,Entlib 的速度会更快,而无需我们完成大量工作。

可供其他库借鉴的经验

Enterprise Library 是一个很好的库示例,它真正利用依赖关系注入容器,而不会与这种容器紧密耦合。如果要编写使用 DI 容器的库,但不希望将自己的选择强加给客户,可以借鉴我们的设计思路。我认为,我们针对“更改”设立的目标,尤其是最后两个,所有 库(而不仅仅是 Entlib)作者都应将其考虑在内:

  • 不使用 DI 的客户不应受在内部使用 DI 的 Entlib 的影响。
  • 确实需要 DI 的客户可以选择所需容器,然后从中获取自己的对象和 Entlib 对象。

设计库时,需要考虑几个问题。请务必考虑以下问题:

  • 库采用什么引导方式?客户是否必须完成特定工作才能设置您的代码,或者,您是否有可正常运行的静态入口点?
  • 您如何对对象图进行建模,以便在配置容器时无需将调用硬编码到该容器中?请参考我们的 TypeRegistration 系统,寻找解决方法。
  • 如何管理要使用的容器?是在内部处理,还是由调用方进行管理?调用方如何通知您要使用哪个容器?

在我们的项目中,我们总结出了一整套很好的答案。希望我们的示例能为您的设计提供帮助。

 


 

Chris Tavares 是 Microsoft 模式和实施方案组的开发人员,在该组中,他任 Enterprise Library 和 Unity 项目的开发主管。在 Microsoft 就职之前,他曾从事咨询、压缩包装软件和嵌入式系统的工作。他在博客中发表了 Entlib、p&p 和常规开发方面的文章,网址为:tavaresstudios.com

 

转载自:http://msdn.microsoft.com/zh-cn/magazine/ee335709.aspx

 

微软企业库5.0 学习之路系列文章索引:

第一步、基本入门

第二步、使用VS2010+Data Access模块建立多数据库项目

第三步、为项目加上异常处理(采用自定义扩展方式记录到数据库中) 

第四步、使用缓存提高网站的性能(EntLib Caching)

第五步、介绍EntLib.Validation模块信息、验证器的实现层级及内置的各种验证器的使用方法——上篇

第五步、介绍EntLib.Validation模块信息、验证器的实现层级及内置的各种验证器的使用方法——中篇 

第五步、介绍EntLib.Validation模块信息、验证器的实现层级及内置的各种验证器的使用方法——下篇

第六步、使用Validation模块进行服务器端数据验证

第七步、Cryptographer加密模块简单分析、自定义加密接口及使用—上篇

第七步、Cryptographer加密模块简单分析、自定义加密接口及使用—下篇

第八步、使用Configuration Setting模块等多种方式分类管理企业库配置信息

第九步、使用PolicyInjection模块进行AOP—PART1——基本使用介绍

第九步、使用PolicyInjection模块进行AOP—PART2——自定义Matching Rule

第九步、使用PolicyInjection模块进行AOP—PART3——内置Call Handler介绍

第九步、使用PolicyInjection模块进行AOP—PART4——建立自定义Call Handler实现用户操作日志记录 

第十步、使用Unity解耦你的系统—PART1——为什么要使用Unity?

第十步、使用Unity解耦你的系统—PART2——了解Unity的使用方法(1)

第十步、使用Unity解耦你的系统—PART2——了解Unity的使用方法(2)

第十步、使用Unity解耦你的系统—PART2——了解Unity的使用方法(3)

第十步、使用Unity解耦你的系统—PART3——依赖注入

第十步、使用Unity解耦你的系统—PART4——Unity&PIAB

扩展学习:

扩展学习篇、库中的依赖关系注入(重构 Microsoft Enterprise Library)[转]

 

posted @ 2010-09-16 14:19 kyo-yo 阅读(...) 评论(...) 编辑 收藏