.net 在 MEF 和 MAF 之间进行选择（System.AddIn）

Choosing between MEF and MAF (System.AddIn)

提问by dthrasher

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.

Managed Extensibility Framework (MEF) 和 Managed AddIn Framework（MAF，又名 System.AddIn）似乎完成了非常相似的任务。根据这个堆栈溢出问题，MEF 是 System.Addin 的替代品吗？，您甚至可以同时使用两者。

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

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

采纳答案by Danielg

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

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

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.

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

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 具有的隔离程度在 MEF 中不存在。它们是用于两种不同事物的两种不同框架。

回答by Scott Whitlock

What Danielg said is good. I would add:

Danielg 说的很好。我会补充：

If you watch the videos about System.Addins, they are clearly talking about very large projects. He talks about one teammanaging the host application, another teammanaging each AddIn, and a third teammanaging the contract and the pipeline. Based on that, I think System.Addins is clearly for larger applications. I'm thinking applications such as ERP systems like SAP (maybe not that big, but you get the idea). If you watched those videos you can tell that the amount of work to use System.Addins is very large. It would work well if you had a lot of companies programming 3rd party add-ins for your system and you can't break any of those add-in contracts under penalty of death.

如果您观看有关 System.Addins 的视频，他们显然在谈论非常大的项目。他谈到一个团队管理宿主应用程序，另一个团队管理每个 AddIn，第三个团队管理合同和管道。基于此，我认为 System.Addins 显然适用于更大的应用程序。我正在考虑诸如 SAP 之类的 ERP 系统之类的应用程序（也许不是那么大，但您懂的）。如果您观看了这些视频，您会发现使用 System.Addins 的工作量非常大。如果您有很多公司为您的系统编写 3rd 方加载项，并且您不能在死刑的情况下违反任何这些加载项合同，那么它会很好地工作。

On the other hand, MEF seems to share more similarities to SharpDevelop's add-in scheme, the Eclipse plugin architecture or Mono.Addins. It's much easier to understand than System.Addins and I believe it to be a lot more flexible. The things you lose are that you don't get AppDomain isolation or strong versioning contracts out-of-the-box with MEF. MEF's strengths are that you can structure your entire application as a composition of parts, so you can ship your product in different configurations for different customers, and if the customer buys a new feature, you just drop the part for that feature into their install directory and the application sees it and runs it. It also facilitates testing. You can instantiate the object you want to test and feed it mock objects for all its dependencies, but when it runs as a composed application, the composition process automatically hooks all the real objects together.

另一方面，MEF 似乎与 SharpDevelop 的插件方案、Eclipse 插件架构或 Mono.Addins 有更多相似之处。它比 System.Addins 更容易理解，我相信它更灵活。你失去的东西是你没有得到 AppDomain 隔离或与 MEF 开箱即用的强版本控制合同。MEF 的优势在于，您可以将整个应用程序构建为多个部分的组合，因此您可以为不同的客户以不同的配置交付产品，如果客户购买了新功能，您只需将该功能的部分放入他们的安装目录中应用程序看到它并运行它。它还有助于测试。您可以实例化要测试的对象，并为其提供所有依赖项的模拟对象，

The most important point I'd like to mention is that even though System.Addins is in the framework already, I don't see a lot of evidence of people using it, but MEF is just sitting there on CodePlex supposedly to be included in .NET 4, and people are already starting to build lots of applications with it (myself included). I think that tells you something about the two frameworks.

我想提到的最重要的一点是，尽管 System.Addins 已经在框架中，但我没有看到很多人使用它的证据，但 MEF 只是坐在 CodePlex 上，据说应该包含在其中.NET 4，人们已经开始用它构建大量应用程序（包括我自己）。我认为这会告诉您有关这两个框架的一些信息。

回答by user151112

Having developed and shipped a MAF application. My views on MAF are somewhat jaded.

已经开发并发布了 MAF 应用程序。我对 MAF 的看法有些厌倦。

MAF is a "de-coupled" system or "loosely-coupled" system at worst. MEF is "coupled" system or "loosely-couple" system at best.

MAF 在最坏的情况下是一个“解耦”系统或“松耦合”系统。MEF 充其量是“耦合”系统或“松散耦合”系统。

MAF benefits that we realized by using MAF are:

我们通过使用 MAF 实现的 MAF 好处是：

1. Installing new or updating existing components while the application is running. The AddIn could be updated while the Application was running and the updates appear to the user seamlessly. You have to have AppDomains for that.

2. Licensing based on purchased components. We could control which AddIn were loaded by the user's role and permissions and whether the AddIn was licensed for use.

3. Rapid development (quicker time-to-market). The AddIn development fits perfectly with Agile methodolgy, the development team developed one AddIn at a time without having to also develop the integration piece with the rest of the application.

4. Improved QA (only QA one component at a time). QA could then test and issue defects for a single bit of functionality. The test cases were easier to develop and implement.

5. Deployment (add components as they are developed and released and they ”just work”). Deployment is only a matter of making an AddIn and installing the file. No other considerations were necessary!

6. New components worked with old components. AddIn that were developed early on kept on working. New AddIns fit into the Application seamlessly

1. 在应用程序运行时安装新组件或更新现有组件。插件可以在应用程序运行时更新，并且更新会无缝地呈现给用户。为此，您必须拥有 AppDomains。

2. 基于购买的组件的许可。我们可以控制用户的角色和权限加载了哪些加载项，以及加载项是否获得使用许可。

3. 快速开发（更快的上市时间）。AddIn 开发与 Agile 方法完美契合，开发团队一次开发一个 AddIn，而不必同时开发与应用程序其余部分的集成部分。

4. 改进的 QA（一次仅对一个组件进行 QA）。然后 QA 可以测试和发布单个功能的缺陷。测试用例更容易开发和实现。

5. 部署（在开发和发布时添加组件并且它们“正常工作”）。部署只是制作插件和安装文件的问题。无需其他考虑！

6. 新组件与旧组件配合使用。早期开发的 AddIn 继续工作。新插件无缝融入应用程序

回答by Raoul

In my view the two technologies actually target very different use cases.

在我看来，这两种技术实际上针对非常不同的用例。

MEF is typically best in a pure dependency injection scenario where the person or group delivering the final integrated solution is assembling everything and vouching for the overall integrity but has a need to have different implementations of key capabilities.

MEF 通常最适合纯依赖注入场景，在这种场景中，交付最终集成解决方案的个人或团队正在组装所有内容并保证整体完整性，但需要对关键功能进行不同的实现。

MAF is for a scenario where someone/group is developing a platform or host and other groups will add capabilities after the fact and in a way not under the control of the host group. In this scenario the need is for more elaborate mechanisms to "protect" the host from rogue add-ins (or to protect add-ins from each other).

MAF 适用于以下场景：某人/组正在开发平台或主机，而其他组将在事后以不受主机组控制的方式添加功能。在这种情况下，需要更精细的机制来“保护”主机免受恶意加载项（或保护加载项之间的相互影响）。

A third similar-in-pattern technology is the whole ProviderBase scheme. This also enables replacing a capability but its goal is really the scenario where the host/app absolutely needs a capability and the need is really to specify different implementations via config.

第三种类似模式的技术是整个 ProviderBase 方案。这也可以替换一个功能，但它的目标实际上是主机/应用程序绝对需要一个功能并且需要真正通过配置指定不同实现的场景。

回答by dthrasher

I just found this lengthy article discussing both MAF and MEF. http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/

我刚刚发现这篇讨论 MAF 和 MEF 的冗长文章。 http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/

In addition to the points made by the other answers, it sounds as if one of the key differences between MEF and MAF is that the Managed Extensibility Framework would allow one composable part to depend on another. It would let a plug-in depend upon another plug-in, for example.

除了其他答案提出的观点之外，听起来好像 MEF 和 MAF 之间的主要区别之一是托管可扩展性框架将允许一个可组合部分依赖于另一个。例如，它会让一个插件依赖另一个插件。

The Managed Extensibility Framework also doesn't really make distinctions between the host and the add-in, as the System.AddIn does. As far as MEF is concerned, they're all just composable parts.

托管扩展性框架也没有像 System.AddIn 那样真正区分主机和加载项。就 MEF 而言，它们都只是可组合的部分。

回答by Matt

In my opinion, the best way to discover the differences is some hands-on code. I found two MSDN walkthroughs, both with a calculator example so you can easily compare their implementations:

在我看来，发现差异的最好方法是一些动手代码。我找到了两个 MSDN 演练，都带有一个计算器示例，因此您可以轻松比较它们的实现：

MEF:Simple calculator example using MEF parts
(Managed Extensibility Framework)

MEF：使用简单的计算器例子MEF部分
（中号anaged êxtensibility ˚Framework）

• Shows how to build up a simple calculator using MEF technology. Does not show how to load external dlls. (But you can simply modify the example by using catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll"));instead of using catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly));and extract the calculator code and contract to separate DLL projects.)

• MEF does notneed to have a specific directory structure, it is simple and straightforward to use, even for small projects. It works with attributes,to declare what is exported, which is easy to read and understand. Example:[Export(typeof(IOperation))] [ExportMetadata("Symbol", '+')] class Add: IOperation { public int Operate(int left, int right) { return left + right; } }

• MEF does not automatically deal with versioning

• 展示如何使用 MEF 技术构建一个简单的计算器。不显示如何加载外部 dll。（但您可以简单地修改示例，使用 catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll"));而不是使用catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly));和提取计算器代码和合同来分离 DLL 项目。）

• MEF不需要特定的目录结构，使用起来简单直接，即使是小型项目。它使用属性来声明导出的内容，这很容易阅读和理解。例子：[Export(typeof(IOperation))] [ExportMetadata("Symbol", '+')] class Add: IOperation { public int Operate(int left, int right) { return left + right; } }

• MEF 不会自动处理版本控制

MAF:Simple calculator with V1 and V2 version MAF plugins
(Managed Addin Framework)

MAF：简单的计算器与V1和V2版本MAF插件
（中号anaged一个ddin ˚Framework）

• Shows how to build up the calculator by using a V1 plugin and then how to move over to a V2 plugin while maintaining backwards-compatibility (note:you can find the V2 version of the plugin here, the link in the original article is broken)
• MAF enforcesa specific directory structure,and it needs a lot of boilerplate code to make it work, hence I don't recommend it for small projects. Example:

  Pipeline
    AddIns
      CalcV1
      CalcV2
    AddInSideAdapters
    AddInViews
    Contracts
    HostSideAdapters
  

• 展示如何使用 V1 插件构建计算器，然后如何在保持向后兼容性的同时转移到 V2 插件（注意：您可以在此处找到该插件的 V2 版本，原始文章中的链接已损坏）
• MAF强制执行特定的目录结构，它需要大量样板代码才能使其工作，因此我不建议将其用于小型项目。 例子：

  Pipeline
    AddIns
      CalcV1
      CalcV2
    AddInSideAdapters
    AddInViews
    Contracts
    HostSideAdapters
  

Both MEF and MAF are included in the .NET Framework 4.x. If you compare the two examples you will notice that the MAF plugins have a lot more complexity compared with the MEF framework - so you need to think carefully when to use which of those frameworks.

MEF 和 MAF 都包含在 .NET Framework 4.x 中。如果您比较这两个示例，您会注意到 MAF 插件与 MEF 框架相比复杂得多——因此您需要仔细考虑何时使用这些框架中的哪一个。

回答by JeffBramlett

MAF and MEF both can use AppDomains and both can load/unload dll in runtime. However the differences I have found are: MAF AddIns are decoupled, MEF components are loose coupled; MAF "Activates" (new instance) while MEF makes instances by default.

MAF 和 MEF 都可以使用 AppDomains，并且都可以在运行时加载/卸载 dll。然而，我发现的不同之处在于：MAF 插件是解耦的，MEF 组件是松耦合的；MAF“激活”（新实例），而 MEF 默认创建实例。

With MEF you can use Generics to make GenericHost for any contract. This means the MEF load/unload and component management can be in a common library and used generically.

使用 MEF，您可以使用泛型为任何合约制作 GenericHost。这意味着 MEF 加载/卸载和组件管理可以在一个公共库中并通用。