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

Question

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

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

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

通过一些研究和实验，我得出了三个选择：

• System.Addin (MAF)： 看来这可以满足我的所有需求。有一个管道允许同时运行多个版本的 API 以实现兼容性等。但除非我遗漏了一些东西，否则我需要多次创建 API - 主机和插件视图、合同和合同的两个适配器。此外，周围的信息和资源很少（与 MEF 相比），而且大多数文章都是几年前的。我担心它正在慢慢消亡，我不想将它用于新项目。

• MEF：这个看似简单，但也感觉有很多魔力无法控制，层层分离没有MAF中那么多.我只想要一个小库，你可以链接到一个新项目，实现接口，插件就完成了。

• 手动加载：最后一个选项是手动扫描文件夹中的 .dlls，使用反射查找插件类并创建实例。虽然可行，但我宁愿使用一些框架，也不愿手动加载程序集、创建单独的进程/应用程序域等。

那么，哪一个最适合这种应用程序，或者我错过了什么？

Answer 1

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

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

这是我的建议，除非有充分的理由选择其他选项。 MAF 有更多的隔离支持，但使用起来要困难得多，而且大多数隔离功能在 WPF 应用程序中将无法使用，因为 WPF 中的 UI 在任何情况下都不能真正成为隔离代码。