在MEF和MAF之间选择(System.AddIn)

Question

托管扩展框架(MEF)和托管AddIn框架(又称System.AddIn)似乎完成了非常相似的任务。根据这个堆栈溢出问题，Is MEF a replacement for System.Addin?，你甚至可以同时使用两者。

什么时候你会选择使用一种而不是另一种？在什么情况下，您会选择同时使用这两个工具？

Answer 1

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

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

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

Answer 2

Danielg说的很好。我要补充的是：

如果你看了关于System.Addins的视频，他们显然是在谈论非常大的项目。他谈到一个team管理主机应用程序，另一个team管理每个AddIn，第三个team管理合同和管道。基于此，我认为System.Addins显然适用于更大的应用程序。我在考虑像SAP这样的ERP系统这样的应用程序(可能没有那么大，但你明白了)。如果你看过这些视频，你就会知道使用System.Addins的工作量非常大。如果你有很多公司为你的系统编写第三方插件，并且你不能违反任何一个被判死刑的插件合同，那么它将会工作得很好。

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

我想提的最重要的一点是，尽管System.Addins已经在框架中了，但我没有看到很多人使用它的证据，但CodePlex只是坐在那里，理应包含在.NET 4中，人们已经开始用它构建很多应用程序(包括我自己)。我认为这告诉了你一些关于这两个框架的信息。

Answer 3

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

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

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

1. 在应用程序运行时安装新组件或更新现有组件。AddIn可以在应用程序运行时进行更新，并且更新可以无缝地呈现给用户。您必须拥有基于已购买组件的that.
2. Licensing AppDomains。我们可以控制用户的角色和权限加载哪些AddIn，以及AddIn是否获得使用许可。
3. 快速开发(更快的上市时间)。QA开发完全符合敏捷方法论，开发团队一次只开发一个QA，而不必开发与application.
4. Improved AddIn其余部分的集成部分(一次只开发一个AddIn组件)。然后，QA可以测试并发布单个功能的缺陷。测试用例更容易开发和implement.
5. Deployment (在开发和发布时添加组件，它们就可以“正常工作”)。部署只需创建一个AddIn并安装文件即可。没有其他考虑因素，因为necessary!
6. New组件可以与旧组件一起工作。早期开发的AddIn继续工作。新的AddIns可以无缝地融入应用程序