问题标签 [inversion-of-control]

从我读过的关于 Windsor/Microkernel 的内容来看，理论上可以使用带有代码的 xml 文件来完成所有可以做的事情。事实上 - 如果我错了，请纠正我 - Windsor 层的主要贡献似乎是为微内核已经可以做的事情添加 xml 配置。

但是，我最近一直在努力寻找如何在代码中实现一些稍微复杂的功能（即如何分配默认构造函数参数值）。现在，虽然我将在我的生产版本中使用 xml，但我正在为我的测试注册代码中的组件，这变得非常有问题。他们文档的不幸状态以及我能找到的唯一文章专注于 xml 注册这一事实无济于事。

有谁知道列出如何在代码中注册事物的来源（最好使用 xml 等价物）？撇开它的存在，有没有人知道一个开源/示例项目，其中有显着的非 xml 使用 Castle Windsor/Microkernel？

可能重复：
哪些 .NET 依赖注入框架值得研究？

StructureMap 和 Ninject 中哪个是最好的 IoC？

这应该与以下内容合并：最佳注入框架

有人可以向我解释使用 IOC 容器相对于简单地将默认实现硬编码到默认构造函数中的优势吗？

换句话说，这段代码有什么问题？

据我所知，这个类足够支持构造函数注入，因此单元测试和模拟很容易完成。除此之外，默认构造函数消除了 IOC 容器的计算开销（更不用说整个过程更加透明）。

我可以看到使用 IOC 容器的唯一好处是如果您需要经常切换接口的实现。我错过了什么吗？

我使用IoC已经有一段时间了，我很好奇是否应该使用微软的Unity框架（正式名称“Unity Application Block”）。有没有人有使用它的经验？所以我一直在将我的 IoC 容器代码从一个项目复制到另一个项目，但我认为使用标准的东西会更好。我认为 IoC 可以在保持基于组件的应用程序松散耦合方面产生巨大的差异，因此可以改变，但我绝不是 IoC 方面的专家，所以我很紧张切换到一个框架，它只会把我描绘成一个依赖我的角落终有一天会想要走开。

MEF（Managed Extensibility Framework）解决了哪些现有IoC/DI容器无法解决的问题？

我正在将城堡温莎用于我正在从事的宠物项目。我开始注意到我需要在代码的不同位置调用 IoC 容器来创建新对象。这种对容器的依赖使我的代码更难维护。

我用过两种解决方案来解决这个问题

我尝试创建抽象工厂作为容器的包装器，我可以将其注入需要创建对象的应用程序部分。这可行但有一些缺点，因为城堡很难将自己的容器作为依赖项注入。所以我必须手动完成，这违背了 IoC 容器的全部目的。

我使用主 applicationcontroller 类来包装 IoC 容器并作为中央工厂/存储库工作。这是相当成功的，但是这个类变得太大了，就像一个中心上帝对象，几乎所有其他对象都有对它的引用。

两种解决方案都有效，但都有其缺点。所以我很好奇其他人是否有同样的问题并找到了更好的解决方案。

编辑 问题不在于依赖于对象B的对象A。在这里我通常只使用构造函数注入并且一切正常。有时我有类型 A 的对象需要在其生命周期内创建可变数量的其他类型 B 的对象。我不知道该怎么做。

@Blair Conrad：到目前为止，维护问题并不严重。我有一些类依赖于容器对象调用 container.Resolve<>。而且我不想让我的代码取决于我认为的基础设施。我仍在尝试，所以我注意到在从 ninject 切换到 Castle 时，我必须更改很多代码。

@花：嗯。我喜欢你的拳头解决方案。它结合了我尝试过的两种解决方案的工作原理。我想我仍然在对象方面考虑太多，而在接口/职责方面考虑得不够。我尝试了专门建造的工厂，但我想让他们在幕后使用容器来创建对象，但我还没有发现如何以干净的方式将容器 DI 转换为对象。

我正在寻找一个 .xsd 架构文件以放入我的 Visual Studio 目录中，以便为 Castle Windsor IoC 容器的 xml 配置文件提供智能感知。我查看了下载的 Windsor 代码，并搜索了几种不同的方法。我看到很多人问同样的问题，但没有答案。谁知道有没有这样的文件？

假设ApplicationSettings类是适用于我的应用程序的设置的通用存储库，例如 TimeoutPeriod、DefaultUnitOfMeasure、HistoryWindowSize 等...假设 MyClass 使用其中一个设置 - DefaultUnitOfMeasure。

我对正确使用控制容器反转的阅读 - 如果我在这方面错了请纠正我 - 是您在其构造函数中定义类的依赖关系：

然后用类似的方法调用实例化你的类

其中IDataSource已被分配一个具体实现，而 default_uom 已被连接以从ApplicationSettings.DefaultUnitOfMeasure属性进行实例化。然而，我不得不怀疑，所有这些箍是否真的有必要跳过。我有什么麻烦我应该怎么做

是的，我的许多课程最终都依赖于IoC.Container，但无论如何我的大多数课程都会有这种依赖。只要类是耦合的，我似乎应该充分利用它。请敏捷大师，告诉我我错在哪里。

所以我可能有 10 个对象，每个对象都有 1-3 个依赖项（就松散耦合而言，我认为这是可以的），还有一些可用于定义行为的设置（超时、窗口大小等）。

现在，在我开始使用控制反转容器之前，我会为每个需要超过 1 个设置的对象创建一个工厂，甚至可能是一个简单的 ObjectSettings 对象，以将构造函数的大小保持在推荐的“小于 4”参数尺寸。我现在正在使用控制容器的反转，我只是看不到它的全部意义。当然我可能会得到一个有 7 个参数的构造函数，但谁在乎呢？无论如何，这一切都由国际奥委会填写。

我在这里遗漏了什么还是这基本上是正确的？

可能重复：
在 MEF 和 MAF (System.AddIn) 之间进行选择

托管可扩展性框架是 System.Addin 的替代品吗？或者它们是互补的？