MEF成熟到足以让公司赌博吗？

Question

我的公司需要重写一个大的单片程序，我希望它使用插件类型架构编写。目前最好的解决方案似乎是MEF，但因为它是一个相当“新”的东西，我很蠢地把我公司的未来（以及我的声誉）押在它上面。

有没有人对MEF解决方案的成熟程度有所了解？

由于

Answer 1

Visual Studio的整个扩展系统现在都建立在MEF上。

也就是说，微软正在为它做食物（就像他们正在使用WPF一样）。

鉴于框架开发人员自己将使用它，您可以非常自信它将继续存在。但是，与任何第一个版本一样，当下一个版本发布时，您几乎可以保证会有一些成长的痛苦。

就个人而言，我会选择它。它肯定比基于紧耦合反射的替代方案更好。

Answer 2

我认为没有必要“打赌MEF”。您的代码对MEF的依赖性非常小。

您可以使用dependency injection的技术将单片应用程序分解为只有一个责任的组件，并将其他组件的知识限制为抽象。有关组件之间可能存在的关系类型的详细概述，请参阅this blog post by Nicholas Blumhardt。

然后，可以使用任何依赖注入框架，甚至手动完成将组件连接到应用程序中。组件逻辑不需要知道容器 - 甚至可能没有容器。

对于MEF，您需要向类中添加导入/导出属性。但是，您仍然可以忽略这些属性，并在没有MEF的情况下重用这些组件，例如通过使用另一个DI框架，如AutoFac。

Answer 3

这是一项相对较新的技术，所以我不确定它是否完全成熟。我相信它会在未来几年内发生相当大的变化，可能会与其他框架合并以更好地支持IoC。也就是说，MS在保持向后兼容性方面有着相当好的历史，所以现在MEF实际上是框架的一部分，我认为公共接口是稳定的。

也就是说，MEF实际上可能不是您项目的正确解决方案。这取决于您的可扩展性需求以及“大”的大小。如果您想支持真正的可扩展性，包括第三方插件的可能性，它会对您的设计职责产生巨大影响。由于您现在需要维护非常稳定的公共接口，因此更难对基础架构进行更改。如果你真的只是在IoC功能之后，你可能会更好地使用真正的IoC框架，这更明确地限制了你的设计责任，以支持你的内部依赖。如果你打赌公司的未来，在我看来，这是一个更大的问题。