在 MEF 和 MAF 之间进行选择(System.AddIn) [英] Choosing between MEF and MAF (System.AddIn)

问题描述

托管扩展框架 (MEF) 和托管加载项框架(MAF，又名 System.AddIn)似乎完成了非常相似的任务.根据这个 Stack Overflow 问题，MEF 是 System.Addin 的替代品吗?，您甚至可以同时使用两者.

The Managed Extensibility Framework (MEF) and Managed AddIn Framework (MAF, aka System.AddIn) seem to accomplish very similar tasks. According to this Stack Overflow question, Is MEF a replacement for System.Addin?, you can even use both at the same time.

你会在什么时候选择使用一种和另一种?在什么情况下你会选择两者一起使用?

When would you choose to use one vs. the other? Under what circumstances would you choose to use both together?

推荐答案

我一直在评估这些选项，这是我得出的结论.

I've been evaluating these options and here's the conclusion that I came to.

MAF 是一个真正的插件框架.您可以完全分离您的插件，甚至可以在单独的应用程序域中运行它们，这样如果插件崩溃，它就不会关闭您的应用程序.它还提供了一种非常完整的方法来将插件与依赖于您提供给它们的合同之外的任何东西分离.事实上，您可以在升级主应用程序时对合同适配器进行版本化，以提供对旧插件的向后兼容性.虽然这听起来很棒，但它伴随着您必须为跨应用程序域付出的沉重代价.您付出的代价是速度和可以来回发送的类型的灵活性.

MAF is a true addon framework. You can separate your addons completely, even running them inside a separate app domain so that if an addon crashes, it won't take down your application. It also provides a very complete way of decoupling the addons from depending on anything but the contract you give them. In fact, you can versionize your contract adapters to provide backwards compatibility to old addons while you are upgrading the main App. While this sounds great, it comes with a heavy price you have to pay in order to cross appdomains. You pay this price in speed and also in the flexibility of the types that you can send back and forth.

MEF 更像是依赖注入，具有一些额外的好处，例如可发现性和......(在这个问题上画一个空白).MAF 具有的隔离程度在 MEF 中不存在.它们是用于两种不同事物的两种不同框架.

MEF is more like dependency injection with some additional benefits such as discoverability and ... (drawing a blank on this one). The degree of isolation that MAF has is not present in MEF. They are two different frameworks for two different things.

这篇关于在 MEF 和 MAF 之间进行选择(System.AddIn)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！