dependency-injection - 为什么 MEF 有 [ImportMany] 而不仅仅是 [Import]

Question

我刚刚在我的 mef 应用程序中发现了一个问题；问题是，我有一个 [Import]而不是 [ImportMany]在我的IEnumerable<IFoo>属性(property)。我开始想为什么。 MEF 看到注入(inject)目标是一个“集合”，并且可以确定需要该集合而不是单个元素。至少 Ninject 是这样工作的。

有谁知道为什么[ImportMany]是必须的？我能想到的唯一原因是有人可能想要 [Export(typeof(IEnumerable<IBar>)] public IEnumerable<Bar> { get; }但这真的是这个设计的原因吗？我敢打赌，我不是唯一一个一直在调试此类错误的人。

Answer 1

不一样;)

[Import]表示您要根据契约(Contract)导入单个事物。在 MEF 中，契约(Contract)只是一个字符串，当您导入一个类型(如 IEnumerable<IBar> )时，您实际上是根据只是该类型的 name 的契约(Contract)进行导入。

在 MEF 中，cardinality 非常重要，因此当您声明希望导入符合规定契约(Contract)的事物的 单个 实例时，只能有一个单一来源。如果找到多个导出，则由于基数不匹配而引发异常。

[Import]功能不包含处理 IEnumerable<T> 的特殊逻辑，所以从它的角度来看，它只是和其他所有东西一样的契约(Contract)。

[ImportMany]然而，属性的存在尤其是为了弥补这一差距。对于所述契约(Contract)，它接受零到任意数量的导出。这意味着 IEnumerable<IBar> 不是 单个 导出你可以有许多个IBar的导出分散在多个程序集中，并且永远不会出现基数不匹配。

归根结底，这是一种设计理念。 MEF 可能拥有关于 IEnumerable<T> 的特殊内置知识。 . Autofac(显然是 Ninject)就是这样做的，并称之为 Relationship Type .

然而，像这样的特殊情况意味着实现代码在某处违反了 Liskov Substitution Principle ，这又会导致 POLA违规，所以在这种情况下，我倾向于站在 MEF 设计者一边。使用更明确的 API 可能会降低可发现性，但可能会更安全。