插件体系结构.net maf or mef

我目前在游戏平台应用程序中工作。我希望能够方便地添加新的游戏，但游戏应该是符合特定的合同：插件体系结构.net maf or mef

本场比赛必须有一些所需的方法
他们必须接受所提供的一些事件主程序
他们必须能够一些数据发送回到程序
这将是美好的，如果很容易为外部开发者做游戏的平台，只是有知识Ø F中的界面

我读到这样MEF的一些问题VS MAF，起初我认为MAF更适合我，但我不知道这一点。另外，我想我甚至可以制作一些自制系统，比如将游戏编译为DLL并在运行时检索它们。

MAF似乎不错，因为隔离的，但因为我不是真的很少外接工作，和我读，MAF重，缺乏速度，我有我应该用什么疑点重重。

我应该尝试MAF吗？即使它可能很慢，很难开发，它真的适合我在做什么吗？

2013-01-03 LeLolDuLol

仅当需要隔离和/或版本控制时才应考虑System.AddIn（MAF），并且只需将主机公开给加载项（Visual Studio和MS Office就是这种情况，两者都使用System据我所知，加入）。另请注意，您可以通过将MEF与Autofac结合使用来进行版本控制（http://nblumhardt.com/2011/01/decorator-support-in-autofac-2-4/）。 –

这可能不会是你的完整答案，但我会在MEF上发出响应，我有经验（我没有真正的MAF经验）。 MEF有很多我认为适合您需求的优势。

MEF重量轻，使用起来非常简单。它提供了一个依赖注入。

发现的东西非常容易使用。只需创建您的目录，然后关闭并运行。

MEF使插件体系结构成为真正的快照。我完全卖了它。

尽管MAF可能会提供隔离，但您必须使可远程调用跨应用程序域，这很麻烦。为了防止未处理的异常将您的主应用程序取出，您必须在自己的进程中创建加载项，这些加载项有其自身的局限性。例如，如果您想在您的加载项中共享DLL，则它们需要与共享DLL或共享DLL需要位于GAC中的目录处于同一目录中。

来源

2013-01-03 20:57:33 Pete

+1此外，如果您决定共享dll，则需要非常小心，因为很可能会丢失System.AddIn（MAF）的版本控制功能。最好只有公共成员永远不会改变的程序集（如.NET框架中的程序集）才能被主机和加载项共享。 –

插件体系结构.net maf or mef

回答

相关问题