11

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

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

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

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

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

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

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

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

4

1 回答 1

10

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

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

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

于 2010-06-24T16:08:06.563 回答