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

Question

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

c#.netwpfmefextensibility

12

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

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

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

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

System.Addin (MAF)：它似乎可以做到我所需要的一切。有一个管道允许同时运行多个版本的API以实现兼容性等。但除非我漏掉了什么，否则我需要创建多个API——宿主和插件视图、契约以及两个适配器用于契约。此外，相比MEF，它的信息和资源相对较少，大多数文章都是几年前的。我担心这正在逐渐消亡，不想在新项目中使用它。
MEF：这个似乎更简单，但也感觉有很多我不能控制的魔法，而且层次结构没有像MAF那样分离。我只希望有一个小库，可以将其链接到一个新项目中，实现接口，插件就完成了。
手动加载：
最后一种选择是手动扫描文件夹中的.dlls，使用反射查找插件类并创建实例。虽然这是可行的，但我宁愿使用一些框架，而不是手动加载程序集、创建单独的进程/应用程序域等。

那么，哪一种方法最适合这种应用程序，或者我有什么遗漏的吗？

- lacop

真是个不错的主题。有几篇相关的好文章：http://pwlodek.blogspot.com/2011/07/isolating-mef-components.html 和 http://blogs.msdn.com/b/tilovell/archive/2011/08/19/wf4-hosting-the-workflowdesigner-or-other-wpf-stuff-in-a-separate-appdomain.aspx。 - user1228

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Reed Copsey · Accepted Answer

MEF绝对是三个选项中最简单的选择。它确实是针对这种情况（可扩展应用程序）而设计的。

它实际上是Visual Studio使用的“插件”机制，它是一个WPF应用程序。你所需要做的就是让你的“插件”实现一个接口或从已知的基类派生，并添加[Export]属性。只要它所在的程序集被添加到主应用程序的目录中，该类型可以通过一步[Import]被主应用程序引入。几乎没有什么工作需要让它正常工作。

除非有强烈的原因选择其他选项，否则我会建议使用MEF。MAF具有更多的隔离支持，但使用起来要困难得多，并且大多数隔离功能在WPF应用程序中无法使用，因为WPF中的UI实际上不能被隔离成代码。