在 MEF 和 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我一直在评估这些选项，这是我得出的结论。
MAF 是一个真正的插件框架。 您可以完全分离您的插件，甚至可以在单独的应用程序域中运行它们，这样如果插件崩溃，它不会关闭您的应用程序。 它还提供了一种非常完整的方法，使插件不再依赖任何东西，除了你给他们的合同。 事实上，您可以在升级主应用程序时对合同适配器进行版本化，以提供对旧插件的向后兼容性。 虽然这听起来不错，但为了跨应用程序域，您必须付出沉重的代价。 您付出的代价是速度以及可来回发送的类型的灵活性。
MEF 更像是依赖注入，具有一些额外的好处，例如可发现性和......（在这一点上画一个空白）。 MEF 中不存在 MAF 所具有的隔离程度。 它们是针对两种不同事物的两种不同框架。
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.
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.
丹尼尔格说得很好。 我想补充一点：
如果您观看有关 System.Addins 的视频，他们显然在谈论非常大的项目。 他谈到一个团队管理主机应用程序，另一个团队管理每个插件，第三个团队管理合约和管道。 基于此，我认为 System.Addins 显然适用于大型应用程序。 我正在考虑诸如 SAP 之类的 ERP 系统之类的应用程序（也许不是那么大，但你明白了）。 如果您看过这些视频，您就会发现使用 System.Addins 的工作量非常大。 如果您有很多公司为您的系统编写第 3 方加载项，并且您不能违反任何这些加载项合同，那么这会很有效。
另一方面，MEF 似乎与 SharpDevelop 的插件方案、Eclipse 插件架构或 Mono.Addins 有更多相似之处。 它比 System.Addins 更容易理解，而且我相信它更灵活。 您失去的东西是您无法通过 MEF 获得开箱即用的 AppDomain 隔离或强大的版本控制合约。 MEF 的优势在于您可以将整个应用程序构建为部件的组合，因此您可以为不同的客户以不同的配置交付产品，如果客户购买新功能，您只需将该功能的部件放入他们的安装目录中即可应用程序看到它并运行它。 它还有助于测试。 您可以实例化要测试的对象，并为它的所有依赖项提供模拟对象，但是当它作为组合应用程序运行时，组合过程会自动将所有真实对象挂钩在一起。
我想提的最重要的一点是，尽管 System.Addins 已经在框架中，但我没有看到很多人使用它的证据，但 MEF 只是坐在 CodePlex 上，据说应该包含在.NET 4，人们已经开始用它构建大量应用程序（包括我自己）。 我认为这告诉你一些关于这两个框架的信息。
What Danielg said is good. I would add:
If you watch the videos about System.Addins, they are clearly talking about very large projects. He talks about one team managing the host application, another team managing each AddIn, and a third team managing 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.
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.
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.
开发并发布了 MAF 应用程序。 我对 MAF 的看法有些厌倦。
MAF 在最坏的情况下是一个“解耦”系统或“松耦合”系统。
MEF 充其量是“耦合”系统或“松散耦合”系统。
我们通过使用 MAF 实现的 MAF 优势包括：
在应用程序运行时安装新组件或更新现有组件。 插件可以在应用程序运行时进行更新，并且更新会无缝地呈现给用户。 为此，您必须拥有 AppDomain。
基于购买的组件的许可。 我们可以通过用户的角色和权限来控制加载哪些 AddIn，以及该 AddIn 是否获得使用许可。
快速开发（更快的上市时间）。 AddIn 开发与敏捷方法完美契合，开发团队一次开发一个 AddIn，而无需同时开发与应用程序其余部分的集成部分。
改进了质量检查（一次仅对一个组件进行质量检查）。 然后，QA 可以测试并发布单个功能的缺陷。 测试用例更容易开发和实施。
部署（在开发和发布时添加组件，并且它们“正常工作”）。 部署只需制作 AddIn 并安装文件即可。 无需其他考虑！
新组件可以与旧组件配合使用。 早期开发的 AddIn 一直在工作。 新插件无缝融入应用程序
Having developed and shipped a MAF application. My views on MAF are somewhat jaded.
MAF is a "de-coupled" system or "loosely-coupled" system at worst.
MEF is "coupled" system or "loosely-couple" system at best.
MAF benefits that we realized by using MAF are:
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.
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.
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.
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.
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!
New components worked with old components. AddIn that were developed early on kept on working. New AddIns fit into the Application seamlessly
在我看来，这两种技术实际上针对的是非常不同的用例。
MEF 通常最适合纯粹的依赖注入场景，在这种场景中，提供最终集成解决方案的个人或团队正在组装所有内容并保证整体完整性，但需要对关键功能进行不同的实现。
MAF 适用于以下场景：某人/团体正在开发平台或主机，而其他团体将在事后以不受主机团体控制的方式添加功能。 在这种情况下，需要更复杂的机制来“保护”主机免受恶意加载项的侵害（或保护加载项免受彼此的侵害）。
第三种类似模式的技术是整个 ProviderBase 方案。 这也可以替换功能，但其目标实际上是主机/应用程序绝对需要功能的场景，并且需要真正通过配置指定不同的实现。
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.
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).
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.
我刚刚发现这篇冗长的文章讨论了 MAF 和 MEF。
http://emcpadden.wordpress.com/2008/ 12/07/managed-extensibility-framework-and-others/
除了其他答案提出的观点之外，听起来好像 MEF 和 MAF 之间的主要区别之一是托管可扩展性框架允许一个可组合部分依赖于另一个部分。 例如，它会让一个插件依赖于另一个插件。
托管扩展性框架也并不像 System.AddIn 那样真正区分主机和加载项。 就 MEF 而言，它们都只是可组合的部分。
I just found this lengthy article discussing both MAF and 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.
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.
在我看来，发现差异的最好方法是一些动手编写代码。 我找到了两个 MSDN 演练，都带有计算器示例，以便您可以轻松比较它们的实现：
MEF： 使用 MEF 部件的简单计算器示例
（管理扩展性框架）
catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll"));而不是使用
catalog.Catalogs.Add(new并提取AssemblyCatalog(typeof(Program).Assembly));
计算器代码和合同到单独的 DLL 项目。）
MEF 不需要有特定的目录结构，它使用起来简单直接，即使对于小型项目也是如此。 它使用属性来声明导出的内容，这很容易阅读和理解。 示例：
<代码>
[导出（类型（IOperation））]
[ExportMetadata("符号", '+')]
类添加：IOOperation
{
公共 int 操作（int 左，int 右）
{
返回左+右；
}
}
MEF 不会自动处理版本控制
MAF： 带有 V1 和 V2 版本MAF 插件的简单计算器
（M管理Addin F框架）
示例：
<块引用>
MEF 和 MAF 都包含在 .NET Framework 4.x 中。 如果比较这两个示例，您会发现 MAF 插件比 MEF 框架复杂得多 - 因此您需要仔细考虑何时使用其中哪个框架。
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:
MEF: Simple calculator example using MEF parts
(Managed Extensibility Framework)
catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll"));instead of using
catalog.Catalogs.Add(newand extract theAssemblyCatalog(typeof(Program).Assembly));
calculator code and contract to separate DLL projects.)
MEF does not need 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
MAF: Simple calculator with V1 and V2 version MAF plugins
(Managed Addin Framework)
Example:
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.
MAF 和 MEF 都可以使用 AppDomains，并且都可以在运行时加载/卸载 dll。 然而，我发现的差异是：MAF AddIn 是解耦的，MEF 组件是松耦合的； MAF“激活”（新实例），而 MEF 默认创建实例。
通过 MEF，您可以使用 Generics 为任何合约创建 GenericHost。 这意味着 MEF 加载/卸载和组件管理可以位于公共库中并通用。
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.
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.