可扩展WPF应用程序 - MEF，MAF还是简单加载？

Question

（我知道其他MEF/MAF问题，但这是一个更具体的问题）

我想创建一个WPF应用程序，将基本上只是一个简单的附加在主机上，图形用户界面和设置。所有的实际工作将由一个或多个插件完成。他们不需要互相沟通，主应用程序会发送用户输入/命令给他们，他们会返回一些结果（例如，WPF UI元素来呈现）。

现在，由于应用程序的核心将基于插件，因此我需要选择一种管理它们的好方法。我希望能够在运行时加载/卸载/重新加载它们（例如，当找到并下载更新时）。他们可能应该在自己的应用领域和/或过程中运行，以确保稳定性和安全性。

从一些研究和实验我来到了三个选项：

• System.Addin（MAF）：看来，这所能做的一切，我需要。有一个流水线允许同时运行多个版本的API以实现兼容性等。但除非我错过了一些我需要多次创建API的地方 - 主机和插件视图，合同和合同的两个适配器。此外，与MEF相比，信息和资源很少，大多数文章都是几年前的文章。我担心这会慢慢死去，宁愿不要将它用于新项目。

• MEF：这一个看起来更简单，但它也觉得有很多魔法我无法控制，并且层没有像MAF那样分开。我只想要一个小型库，您可以链接到一个新项目，实现该接口并完成插件。

• 手动加载：的最后一个选项将是为的.dll手动扫描文件夹，使用反射来寻找插件类和创建实例。虽然它是可行的，我宁愿用一些框架比手动加载组件，创建单独的进程/应用程序域等

那么，哪一个将是最适合这种应用，或者是有什么说我”错过了？

Answer 1

MEF绝对是三者中最简单的选择。它确实是在设计时考虑到了这种确切的场景（可扩展应用程序）。

它实际上是Visual Studio使用的“插件”机制，这是一个WPF应用程序。所有你需要做的就是让你的“插件”实现一个接口或从已知的基类派生，并添加[Export]属性。只要它的程序集被添加到主应用程序的目录中，该类型可以由主应用程序在一个步骤中编辑[Import]。这项工作涉及很少的工作。

这将是我的建议，除非有很强的理由去用不同的选项。 MAF具有更多的隔离支持，但使用起来更加困难，并且大多数隔离功能在WPF应用程序中不可用，因为在任何情况下，WPF中的UI都无法真正被隔离。