c# - MEF 最佳实践 : Where in the application I create container and where to call Compose()?

Question

我已决定将 MEF 用于我拥有的插件模式，并且发现 MEF 易于上手且完全没有干扰。我查看了示例，发现它们非常易于使用。

然而，一旦开始实现，我就开始为构图而苦恼。假设我有一个在其属性之一上具有 [ImportMany] 的类。我见过的所有示例，它们在具有导入的类中创建容器(我们称之为可组合)并且基本上类自行组合。对于一个示例来说，这可能没问题，但对于可组合项来说，关于插件如何填充的知识肯定太多了。

我可以愉快地创建一个单例容器并在我的可组合项中访问它，但可组合项必须再次显式调用 Compose() 自身，我对此也不满意，因为它就像一个依赖项类主动调用容器上的 Resolve() 的注入(inject)场景。所以我不想将它仅用于服务位置。

更糟糕的是，我还在使用 Windsor CaSTLe 进行 DI，但我不确定 MEF 和 Windsor 必须如何协同工作。

我确实环顾四周，但未能找到有关如何正确执行 MEF 的任何指导和示例。现在可能是我没有环顾四周，或者我对 MEF 不够了解(这是事实)，但会根据您在现实世界中实际使用它的经验来重视您的观点。

Answer 1

不要那样做。我在上一个项目中使用了 MEF，但我不希望这样做。

它背后有一个好主意(组合)，多年来我一直在手动完成它。我为 .NET 4.0 的第一个正式版本感到高兴，但仍然存在很多设计问题。

不幸的是，将测试和错误发现留给最终用户并反馈来之不易的错误和建议是 Microsoft 政策的一部分。

MEF 如果您按照示例所说的方式使用，则很好。一旦你需要一点改变，你会发现没有足够的文档而且没有人会回答你。以下是一些我从 Unresolved MEF 问题，您可以在 codeplex.com 中找到我的问题。开发团队从未回答过:

1) 如何将参数传递给部分的构造函数(他们可能会说使用 ExportFactory，它在 codeplex 版本中提供，但我在这上面浪费了很长时间，我可以说没有一个可接受的解决方案那个)

2) 如何设置零件配置？ (我最终通过一种坏主意但最好的方法将配置传递给零件)

3) MEF 非常慢，因为它在后台使用了反射。对于我的案例，加载 1,000 个零件需要 60 秒。

4) 调试很棒。您收到不清楚的消息。您最终将从 codeplex 下载完整源代码并在代码中搜索您的异常。

毕竟我认为如果你有其他选择，让MEF成熟并使用下一个版本。

我只是分享了我自己的经历。