一、为什么用MEF
首先看一下，我们如何在控制器中调用业务层的接口：
public class ValuesController : ApiController { private IDBConn dbConn = new SqlConn(); public string DBConnection() { dbConn.Conn(); return "Success"; } }
我们首先声明了一个IDBConn接口，然后用SqlConn来实例化该接口，似乎没有什么不妥的地方。
可是想一下我们为什么使用接口呢？
接口和实现分离了，适于团队的协作开发，主要为了实现松散耦合的系统，便于以后升级，扩展。
我们使用接口的实现直接去实例化接口，似乎并没有起到松耦合的目的，白白增加了接口，并没有任何用处，与下图的方式没有任何的区别。
public class ValuesController : ApiController { private SqlConn dbConn = new SqlConn(); public string DBConnection() { dbConn.Conn(); return "Success"; } }
那么问题来了，我们直接使用第二种方式不就可以了吗？答案是也不好，因为这样违背了依赖倒置原则：
高层模板不应该依赖底层模板，两者应该依赖于抽象，而抽象不应该依赖于细节。
在模块编程中要依赖抽象编程，不要依赖具体的细节编程，即针对接口编程，不要针对具体的实现编程。
到这里我们就可以引入我们的MEF框架，来解决上述的问题。
二、概念
MEF (Managed Extensibility Framework) 使开发人员能够在其 .NET 应用程序中提供挂钩，以供用户和第三方扩展。可以将 MEF 看成一个通用应用程序扩展实用工具。
MEF 使开发人员能够动态创建扩展，无需扩展应用程序，也不需要任何特定于扩展内容的知识。这可以确保在编译时两者之间不存在耦合，使应用程序能够在运行时扩展，不需要重新编译。MEF 还可以在将扩展加载到应用程序之前，查看扩展程序集的元数据，这是一种速度更快的方法。
还没几个需要我们了解的名词：
Contract：契约，即一种约定
Part：部件，即契约的实现
Catalog：目录（理解意义），存放部件的地方，当需要某个部件时，会在目录中寻找
Container：容器，存放目录并进行部件管理，如导出、导入等
Compose：组装，通过容器在目录中寻找到实现了相应契约的部件，进行部件的组装
Export：导出，是部件向容器中提供的一个值, 可修饰类、字段、属性或方法
Import：导入，从容器中获得可用的导出, 可修饰字段、属性或构造函数参数
三、示例
添加System.ComponentModel.Composition引用
修改被调用方法
public interface IDBConn { void Conn(); } [Export("SqlConn", typeof(IDBConn))] public class SqlConn : IDBConn { public void Conn() { Console.WriteLine("this is SqlServer connection"); } }
修改调用方法
public ActionResult Index() { // 创建一个程序集目录，用于从一个程序集获取所有的组件定义 var assemblyCatalog = new AssemblyCatalog(Assembly.GetExecutingAssembly()); //创建容器 var Container = new CompositionContainer(assemblyCatalog); //获得容器中的Export IDBConn _conn = Container.GetExportedValue<IDBConn>("SqlConn"); //调用方法 SqlConn的Conn方法 _conn.Conn(); return View(); }
这样就完全符合依赖倒置原则了，控制器层并没有直接依赖到SqlConn类，而是根据我们的ContractName找到了SqlConn，从而解决了上层依赖下层的强耦合问题。
现在，有了新的需求了，我们的系统需要连接MySql数据库了。
[Export("MySqlConn", typeof(IDBConn))] public class MySqlConn : IDBConn { public void Conn() { Console.WriteLine("this is MySqlConn connection"); } }
这样我们原来的调用方法似乎还是可以用，但是有一点小问题，每次切换数据库，我们都要修改代码，这样不是很好，我们可以把ContractName配置到配置文件中每次通过修改配置文件，实现动态切换数据库。
现在我们又遇到了一个问题，接口要根据版本还会有不同的实现，这样的话，原来的方法也可以，我们可以把原来的ContractName后面加上版本号，这样就能区别开不同版本的实现了。
我们还有更好的办法来解决这个问题，在这里我们引入这个元组这个概念，我们可以在导出时，添加一个特殊字段，供我们来筛选实现。
[ExportMetadata("Version", "v1.0.1")] [Export("SqlConn", typeof(IDBConn))] public class SqlConn : IDBConn { public void Conn() { Console.WriteLine("this is SqlServer connection"); } }
然后我们定义一个元组的接口：
public interface IDBConnMetadata { string Version { get; } }
在调用的时候，进行筛选：
public string TestMetadata() { // 创建一个程序集目录，用于从一个程序集获取所有的组件定义 var assemblyCatalog = new AssemblyCatalog(Assembly.GetExecutingAssembly()); //创建容器 var Container = new CompositionContainer(assemblyCatalog); var export = Container.GetExports<IDBConn, IDBConnMetadata>(); //筛选version为v1.0.1的 IDBConn _conn = export.Where(p => p.Metadata.Version.Equals("v1.0.1")).FirstOrDefault().Value; _conn.Conn(); return ""; }
四、扩展
1.构造方法注入
我们也可以采用构造方法注入的方式：
[Export("TestB")] public class TestB { private IDBConn _conn; [ImportingConstructor] public TestB([Import("SqlConn")]IDBConn conn) { _conn = conn; } public bool IsInject() { if (_conn == null) { return false; } else { return true; } } }
调用时也与其他方式的调用完全一致，不需要特殊处理：
public string TestInject() { // 创建一个程序集目录，用于从一个程序集获取所有的组件定义 var assemblyCatalog = new AssemblyCatalog(Assembly.GetExecutingAssembly()); //创建容器 var Container = new CompositionContainer(assemblyCatalog); var x = Container.GetExportedValue<TestB>("TestB"); bool result = x.IsInject(); return result.ToString(); }
2.导入导出方法
MEF的导出支持类型，属性，方法和字段，在这里我们说一下导出方法，导出方法需要了解一些匿名委托的知识，自行百度一下，很简单。
public class TestClass { private TestClass() { } [Export("GetStr", typeof(Func<string>))] private string GetStr() { return "随便试试字符串"; } [Export("GetLength", typeof(Func<string, int>))] public int GetLength(string str) { return str.Length; } }
我们把TestClass类的构造方法的访问修饰符设置为private级别。私有构造方法，又不是单例，我们如何调用这个类里的方法就是个问题了，那么我们尝试用MEF调用：
private void TestActionWithPara() { // 创建一个程序集目录，用于从一个程序集获取所有的组件定义 var assemblyCatalog = new AssemblyCatalog(Assembly.GetExecutingAssembly()); //创建容器 var Container = new CompositionContainer(assemblyCatalog); //执行组合 Container.ComposeParts(); var action = Container.GetExport<Func<string>>("GetStr"); string message = action.Value.Invoke(); } private void TestActionWithParaAndReturn() { // 创建一个程序集目录，用于从一个程序集获取所有的组件定义 var assemblyCatalog = new AssemblyCatalog(Assembly.GetExecutingAssembly()); //创建容器 var Container = new CompositionContainer(assemblyCatalog); //执行组合 Container.ComposeParts(); var action = Container.GetExport<Func<string, int>>("GetLength"); int length = action.Value.Invoke("GetLength"); }
完全可以访问，并没有因为私有构造方法而造成不能访问，并且上面的GetStr方法也是私有的，依旧可以访问。
这就恶心了，方法的访问修饰符完全被MEF破坏了。。。
感觉这应该算一个bug吧，不过MEF提供了一个属性，可以让方法或者类不能被使用[PartNotDiscoverable]。
五、改进
上面就是MEF的一些基本使用方法，但是写了这么久发现了似乎有一点问题。
每次调用都去创建目录，创建容器，执行组合，似乎太繁琐了，而且重复这些操作，明显也会浪费资源，所以我们可以做一下改进，将这些重复步骤提炼出来一个单独的方法，供其他方法调用。
public class IOCContainer { public static CompositionContainer Container { get; private set; } private static IOCContainer instance = new IOCContainer(); private IOCContainer() { if (Container == null) { //AssemblyCatalog：表示从程序集中搜索部件的目录 // 创建一个程序集目录，用于从一个程序集获取所有的组件定义 var assemblyCatalog = new AssemblyCatalog(Assembly.GetExecutingAssembly()); //指定加载某个程序集 //var directoryCatalog = new DirectoryCatalog("要加载dll的路径"); //AggregateCatalog：聚合目录，可以添加上面所说的所有目录，从而进行多方面的部件搜索 //var aggregateCatalog = new AggregateCatalog(assemblyCatalog, directoryCatalog); //创建容器 Container = new CompositionContainer(assemblyCatalog); //container = new CompositionContainer(aggregateCatalog); //container.GetExportedValue //执行组合 【组合这一行代码，并不影响我们的使用，有没有皆可】 Container.ComposeParts(); } } public static IOCContainer RegisterContainer() { return instance; } }
写好了容器，我们可以在Global.asax中调用RegisterContainer方法，其他使用容器的地方，改为IOCContainer.Container.GetExport就ok了，既简化了代码，也节约了资源。