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

Question

MEF和MAF(System.AddIn)之间的选择托管扩展框架(MEF)和托管Addin框架(MAF，又名System.AddIn)似乎完成了非常类似的任务。根据堆栈溢出问题，MEF是System.Addin的替代品吗？，甚至可以同时使用。你什么时候会选择使用其中一种来对抗另一种呢？在什么情况下，你会选择将两者结合使用？

Answer 1

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

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

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

Answer 2

如果您看了关于System.Addins的视频，他们显然是在谈论非常大的项目。他说起一个团队管理主机应用程序，另一个团队管理每个Addin，以及第三个团队管理合同和管道。基于此，我认为System.Addins显然适用于更大的应用程序。我在考虑像SAP这样的ERP系统(也许没那么大，但你懂)。如果您观看了这些视频，您可以知道使用System.Addins的工作量非常大。如果你有很多公司为你的系统设计第三方插件，而且你不能违反任何死刑附加合同，这会很好。

另一方面，MEF似乎与SharpDe信封的外接程序、Eclipse插件架构或Mono.Addins有更多相似之处。它比System.Addins容易得多，而且我相信它要灵活得多。您所失去的是，您没有得到AppDomain隔离或强大的版本控制合同的框外与MEF。MEF的优点是，您可以将整个应用程序构建为一个部件组合，这样您就可以为不同的客户以不同的配置交付产品，如果客户购买了一个新功能，您只需将该功能的部分放到他们的安装目录中，应用程序就会看到并运行它。它还有助于测试。您可以实例化要测试的对象，并为其所有依赖项提供模拟对象，但当它作为组合应用程序运行时，组合过程会自动将所有实际对象连接在一起。

我想提到的最重要的一点是，尽管System.Addins已经在框架中，但我没有看到很多人使用它的证据，但是MEF只是坐在CodePlex上，据说它包含在.NET 4中，而且人们已经开始用它构建许多应用程序(包括我自己)。我认为这说明了这两个框架的一些情况。

Answer 3

已经开发并交付了MAF应用程序。我对MAF的看法有点令人厌烦。

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

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

1. 在应用程序运行时安装新组件或更新现有组件。在应用程序运行时，可以更新Addin，用户可以无缝地看到更新。你得找阿普曼人才行。

2. 根据购买的部件发放许可证。我们可以控制哪个Addin是由用户的角色和权限加载的，以及Addin是否被授权使用。

3. 快速发展(更快的上市时间)。Addin开发非常适合敏捷方法，开发团队一次开发一个Addin，而不必与应用程序的其他部分开发集成部分。

4. 改进的QA(一次只有QA一个组件)。然后，QA可以测试并发布一段功能的缺陷。测试用例更易于开发和实现。

5. 部署(在开发和发布组件时添加组件，它们“正常工作”)。部署只是制作一个Addin和安装文件的问题。没有其他的考虑是必要的！

6. 新组件与旧组件一起工作。早期开发的Addin继续工作。与应用程序无缝匹配的新加载项