c# - 可扩展的 WPF 应用程序 - MEF、MAF 或简单加载？

Question

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

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

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

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

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

• MEF:这个看起来比较简单，但也感觉有很多我无法控制的魔力，而且层没有像 MAF 那样分离.我只想要一个小库，您可以链接到一个新项目，实现接口(interface)并完成插件。

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

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

Answer 1

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

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

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