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

Question

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

我想创建一个WPF应用程序,它基本上只是一个简单的外接程序主机,GUI和设置.所有实际工作都将由一个或多个插件完成.它们不需要在彼此之间进行通信,主应用程序将向用户发送用户输入/命令,并且它们将返回一些结果(例如,要呈现的WPF UI元素).

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

从一些研究和实验中我得出三个选择:

• System.Addin(MAF):看来这可以做我需要的一切.有一个管道允许同时运行多个版本的API以实现兼容性等.但除非我遗漏了一些东西,否则我需要多次创建API - 主机和插件视图,合同和两个适用于合同的适配器.此外,与MEF相比,信息和资源也很少,而且大多数文章都是几年之久.我担心这会慢慢死去,宁愿不用它来做一个新项目.

• MEF:这个看起来更简单,但也感觉有很多我无法控制的魔法,并且这些层没有像MAF那样分开.我只想要一个小型库,你可以链接到一个新项目,实现界面,插件就完成了.

• 手动加载:最后一个选项是手动扫描.dll文件夹,使用反射来查找插件类和创建实例.虽然它是可行的,但我宁愿使用一些框架而不是手动加载程序集,创建单独的进程/ appdomain等.

那么,哪一种最适合这种应用,还是有一些我错过的东西？

Answer 1

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

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

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