2

我正在研究 MEF 作为我们现有 .NET 应用程序中插件解析的解决方案。

在我能找到的所有示例中，主应用程序都会创建一个 CompositionContainer 实例并调用 container.ComposeParts(this)。

问题是，我的应用程序并非完全建立在 MEF 之上，因此对象图中存在一个没有 MEF 组件的漏洞。所以我的对象层次结构可能如下所示：

应用程序（MEF 容器）-> ObjectB（无 MEF）-> ObjectA（需要 MEF 导入）

在这个对象层次结构中，我不可能在应用程序上调用 container.ComposeParts(this) 并期望应用程序创建 ObjectB 并满足 ObjectA 的 Imports。

全局公开 CompositionContainer 是否是一种好习惯，以便我可以在应用程序启动之后的时间组合 ObjectA，或者我是否必须重组整个应用程序以支持线性 MEF 对象图？

4

1 回答 1

2

全局公开 CompositionContainer 是否是一种好习惯

我不会把它称为一个好的做法，但是当不可能在任何地方引入控制反转原理来构建时，它是一个合理的折衷方案。有时现有的代码库并不完全在您的控制之下，或者是 .NET 和本机代码（例如 COM 组件）的复杂混合，或者只是太大而无法重构。

在 Silverlight 中，从 XAML 构建对象也不受 MEF 控制，因此 Microsoft 引入了基本相同的解决方案：默认 MEF 容器可作为全局访问并使用PartInitializer.SatisfyImports(this);.

请注意，遵循此模式会将全局的任何消费者紧密耦合到 MEF 以及用于公开它的全局变量。无法在其他应用程序或其他 IoC 容器中按原样重用此代码。它也会使单元测试复杂化。

于 2010-06-29T21:39:51.313 回答