用了很久的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