对于这样的应用程序架构,MEF 实际上是一个很好的方式。说“没有那么多应用程序使用 MEF”并不完全正确,因为使用 MEF 的(可能)最大和最知名的应用程序是 Visual Studio 本身(从版本 12.0 - 2013 开始)。
现在,对 MEF 存在一些误解。有 3 个(嗯,三个半)版本(口味)的 MEF 可用。这常常使人们感到困惑。
让我试着解释一下:
- MEF 1.0,也称为 .NET Framework MEF。最初与 .NET Framework 4.0 一起发布;命名空间
System.ComponentModel.Composition
。
- 优点:.NET 框架的一部分;非常灵活和动态
- 缺点:(相对)慢;没有进一步发展
- MEF 2.0,也称为 NuGet MEF。Microsoft 想要一个更快的 Windows Phone 应用程序版本,并且不需要那种完全动态的方法。最初仅针对移动平台发布,然后可用于其他框架。它可以通过NuGet或使用 .NET Core FX 获得。命名空间
System.Composition
。
- 优点:快;现在是 .NET Core FX 的一部分
- 缺点:相对“静态”;启动性能差
- MEF 1.0+,有时被错误地称为 MEF 2.0。这是与 .NET Framework 4.5 一起发布的 MEF 1.0 更新。利弊见 MEF 1.0。
- VS-MEF,一种用于 Visual Studio 的特殊 MEF 风格。可以通过NuGet获得;另请参阅GitHub。命名空间
Microsoft.VisualStudio.Composition
。
- 优点:结合了 MEF 2.0 的良好性能和几乎与 MEF 1.0 相同的灵活性;正在积极开发中
- 缺点:没有动态重组
这些 MEF 版本当然有一些差异,但是这些版本中的任何一个都可以用于基于动态插件的应用程序。根据您的需要,您可以选择其中之一。现在,我推荐 MEF 2.0 (NuGet MEF) 或 VS-MEF。我对 VS-MEF 有过实践经验,对它的功能集和性能非常满意。
但是,MEF 并不是唯一的方法。总是有一个选项可以为基于插件的应用程序创建一个本土平台。事实上,很多公司都是这样走的。
另一种可能性(如果您有基于 IoC 的架构)是使用一些可用的 IoC 容器(如 Unity)并在需要时手动扩展其功能。