Castle Windsor CollectionResolver：为什么它不适用于 Resolve 调用？答案

【问题标题】：Castle Windsor CollectionResolver: Why doesn't it work on Resolve calls?Castle Windsor CollectionResolver：为什么它不适用于 Resolve 调用？
【发布时间】：2011-08-17 10:44:01
【问题描述】：

我已将CollectionResolver 添加为我的 Windsor 内核的子解析器，它将正确地注入已解析对象的依赖项集合。也就是说，如果我有

class X { public X(IComponent[] components) { ... } }
container.Register(/* lots of IComponents */);
container.Register(Component.For<X>());

当我解决它时，构造函数的 components 参数是正确构造的

container.Resolve<X>()

但如果我只想自己获取组件列表，

container.Resolve<IComponent[]>()

我收到一个ComponentNotFound 异常，抱怨我没有为IComponent[] 注册任何组件。我发现这种不对称是违反直觉的，因为我不确定为什么内核在解决它在构造函数/属性上找到的依赖项时与它在解决用户希望它解决的依赖项时的行为不同。

【问题讨论】：

标签： castle-windsor ioc-container

【解决方案1】：

Resolve/ResolveAll 的显式划分是由于容器中的内部和无趣的实现细节。集合解析器是一个子依赖解析器，因此它仅适用于依赖项。

我同意这不是很直观。随时在 Windsor 的问题跟踪器中记录一张票。

【讨论】：

“我同意这并不是不直观。”我假设你的意思是它不是很直观。

【解决方案2】：

我猜这种行为的原因是在构造函数或属性注入中，Castle 使用集合/数组表示法作为指示所有实现都应该在集合中返回。否则，您将需要一个特殊的接口或属性来告诉它。然后你必须在各处显式引用 Castle 的程序集。

但是，当直接从容器解析时，您实际上是在指定需要解析的类型，并且可以更具表现力（使用 API），并且可以显式调用 ResolveAll。所以我想这是一种设计妥协——实现 IoC 容器并不是那么简单，因为你经常受到语言结构的约束。

【讨论】：