我正在研究MEF作为我们现有.NET应用程序中插件解析的解决方案。
在我能找到的所有示例中，主应用程序创建了CompositionContainer的一个实例并调用了container.ComposeParts（this）。
问题是，我的应用程序并非完全基于MEF构建，因此对象图中有一个没有MEF组件的漏洞。 所以我的对象层次结构可能如下所示：
应用程序（MEF容器） - ＆gt;对象B （没有MEF） - ＆gt; ObjectA（需要MEF 进口）
在这个对象层次结构中，我不可能在应用程序上调用container.ComposeParts（this）并期望应用程序创建ObjectB并满足ObjectA的Imports。
在全局公开CompositionContainer是一个好习惯，这样我可以在以后的时间比在Application Startup上编写ObjectA，还是必须重构我的整个应用程序以支持线性MEF对象图？
答案 0 :(得分：2)
暴露这个是一个好习惯 CompositionContainer全球
我不认为这是一个好的做法，但是当不可能在任何地方引入控制原理的反转时，这是一个合理的妥协。有时现有的代码库并不完全在您的控制之下，或者是.NET和本机代码（例如COM组件）的复杂混合，或者只是太大而无法重构。
在Silverlight中，XAML中对象的构造也不在MEF的控制之下，因此Microsoft引入了基本相同的解决方案：默认的MEF容器可以作为全局访问，并使用PartInitializer.SatisfyImports(this);调用。
请注意，遵循此模式会将全局的任何消费者与MEF以及用于公开它的全局变量紧密联系在一起。在其他应用程序中或与其他IoC容器一起使用此代码是不可能的。它还会使单元测试复杂化。