MEF是否成熟到足以让公司押注？
我的公司需要重写一个大型整体程序，我希望它使用插件类型架构来编写。目前最好的解决方案似乎是 MEF，但由于它是一个相当“新”的事物，我对将公司的未来（以及我的声誉）押在它身上持谨慎态度。
有人知道 MEF 解决方案有多成熟吗？
谢谢
My company needs to rewrite a large monolithic program, and I would want it written using a plugin type architecture. Currently the best solution appears to be MEF, but as it is a fairly 'new' thing I am warey of betting the future of my company (and my reputation) on it.
Does anyone have a feeling on how mature a solution MEF is ?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Visual Studio 的整个扩展系统现在构建在 MEF 上。
也就是说，Microsoft 正在对其进行测试（就像他们对 WPF 所做的那样）。
鉴于框架开发人员自己将使用它，您可以非常有信心它会继续存在。然而，与任何第一个版本一样，当下一个版本发布时，您几乎肯定会遇到一些成长的烦恼。
就我个人而言，我会这么做。它肯定比基于紧耦合反射的替代方案更好。
Visual Studio's entire extension system is now built on MEF.
That is to say that Microsoft is Dog-fooding it (like they are doing with WPF).
Given that the framework developers themselves will be working with it, you can feel pretty confident that it is here to stay. However, as with any first release, you are almost guaranteed to have some growing pains when the next release comes around.
Personally, I would go for it. It is certainly better than the tightly-coupled-reflection-based alternative.
我认为没有必要“押注MEF”。您的代码对 MEF 的依赖性应该很小。
您可以使用依赖注入技术将单体应用程序分解为仅具有单一责任，这将他们对其他组件的了解限制为抽象。请参阅 Nicholas Blumhardt 撰写的这篇博文，了解该类型的详细概述组件之间可能存在的关系。
然后可以使用任何依赖项注入框架甚至手动将组件连接到应用程序中。组件逻辑不需要知道容器——甚至可能没有容器。
对于 MEF，您确实需要向您的类添加导入/导出属性。但是，您仍然可以忽略这些属性并在没有 MEF 的情况下重用这些组件，例如使用另一个 DI 框架，例如 AutoFac 。
I don't think it is necessary to "bet on MEF". Your code should have very little dependencies on MEF.
You can use the technique of dependency injection to break up your monolithic application into components which have only a single responsibility, and which limit their knowledge of other components to abstractions. See this blog post by Nicholas Blumhardt for a nice overview of the type of relations that can exist between components.
Wiring the components together into an application can then be done with any dependency injection framework, or even manually. The component logic shouldn't need to be aware of the container - there might not even be a container.
In the case of MEF, you do need to add import/export attributes to your classes. However, you can still ignore those attributes and reuse those components without MEF, e.g. by using another DI framework like AutoFac.
这是一项相对较新的技术，所以我不确定它是否完全成熟。我确信它在接下来的几年里会发生很大的变化，也许会与其他框架合并以更好地支持 IoC。也就是说，MS 在保持向后兼容性方面拥有相当好的历史，因此现在 MEF 实际上是框架的一部分，我认为公共接口是稳定的。
也就是说，MEF 实际上可能不是适合您的项目的解决方案。这取决于您的可扩展性需求以及“大”的大小。如果您想支持真正的可扩展性，包括第三方插件的可能性，它会对您的设计职责产生巨大影响。对基础设施进行更改要困难得多，因为您现在需要维护非常稳定的公共接口。如果您真的只追求 IoC 功能，那么使用真正的 IoC 框架可能会更好，它更明确地限制您的设计责任以支持内部依赖项。在我看来，如果你押注的是公司的未来，那么这是一个更大的问题。
It's a relatively new technology, so I'm not sure if it's exactly mature. I'm sure it will change quite a bit over the next several years, perhaps merging with other frameworks to better support IoC. That said, MS has a pretty good history of preserving backwards compatibility, so now that MEF is actually part of the Framework, I would consider the public interfaces stable.
That said, MEF might not actually be the right solution for your project. It depends on your extensibility needs and how large is 'large'. If you want to support true extensibility, including the possibility for third-party plugins, it has an enormous impact on your design responsibilities. It's much harder to make changes to the infrastructure as you now need to maintain very stable public interfaces. If you're really only after the IoC features, you're probably better off with a true IoC framework, which more clearly limits your design responsibility to support of your internal dependencies. If you're betting the future of the company, this is the bigger question, in my mind.