MEF学习总结---总体架构

Posted 2020-10-12

用了很久的MEF框架来做依赖注入，最近想把它的原理和机构总结一下，主要包括如下几个方面：

1. 总体架构

2. .Net Composition Primitive

3. Attribute Model Programing/Life cycle

4. Container/Recomposition

什么是MEF　　　　　　　　　　　　

用官方的话说：Managed Extensibility Framework（MEF）是.NET平台下的一个扩展性管理框架。个人理解为依赖注入。将所有模块依赖的组件，或者能提供的组件通过MEF的方式注册到框架。然后通过框架所提供的API来获取依赖的对象。

整体架构如下图：

上层的Container层提供了一系列上层API，用来将MEF框架Host在Application中,以及触发依赖的注入和管理注册的。其中ExportProvider主要负责根据依赖定义信息去找到对应的实例。

中间的Primitives层将真实世界中的依赖，提供依赖的表达，发现和应用进行了通用的模型定义。

AttributedProgrammingModel是对Primitives层的一个默认上层实现，它通过Import,Export等Attribute来定义Primitives层中所定义的依赖和提供依赖，也提供了对应的Catalog将依赖定义信息转化为Primitives定义的通用模型。

注: 上图中有几个基本概念：

 Catalog:上图中AssemblyCatalog,TypesCatalog,DirectoryCatalog都属于Catalog,它负责将依赖定义转化为通用的Primitive模型。

 ExportProvider:上图中CompositionContainer,AggregateExportProvider,CatalogExportProvider都属于Export Provider,他负责根据依赖的定义信息去找到匹配的依赖对象实例)

 Part: MEF中的对依赖组建的描述和包装，一个ComposablePart就是一个可以注入的依赖的实例包装。

 

所以MEF的整体工作机制为:

1. 通过Attribute Programming Model定义依赖信息。

2. 通过Container层提供的API将依赖信息注册到MEF容器(CompositionContainer)，ComposiblePartsCatalog会发现在第1步中所定义的依赖信息，并将其转化为Primitives层中定义的通用模型。

3. 通过Container层提供的API来注入依赖时，Container层中的Export Provider通过Primitives层定义的获取依赖的接口来填充所依赖的对象。

上面的工作机制可以描述为下图：

因为第一步定义的依赖信息会在第二部中被ComposiblePartsCatalog转化为通用模型，因此MEF本身是可扩展的，只需要自定义一套定义依赖信息的机制，然后自定义ComposiblePartsCatalog即可扩展MEF。这就是架构图中的Custom Programing Model.

Reference:https://github.com/MicrosoftArchive/mef