问题标签 [inversion-of-control]

第一次遇到控制反转 (IoC) 时可能会非常混乱。

1. 它是什么？
2. 它解决了哪个问题？
3. 什么时候适合使用，什么时候不适合？

哪些 C#/.NET 依赖注入框架值得研究？关于它们的复杂性和速度，你能说什么。

我正在使用 Castle Windsor 进行一些依赖注入，特别是我已将 DAL 层抽象为现在由 DI 加载的接口。

一旦项目被开发和部署，所有 .bin 文件都将位于同一位置，但是当我在 Visual Studio 中开发时，我能看到的唯一方法是将依赖注入项目的 .bin 文件放入启动项目的 bin文件夹要么有一个将其复制进去的构建后事件，要么是手动引用 DAL 项目以将文件拉入。

我对这两种解决方案都不完全满意，所以我想知道是否有解决这个问题的“标准”方法？

我绝对需要使用 IoC 容器来解耦日益复杂的企业服务系统中的依赖关系。我面临的问题与配置（又名注册）有关。我们目前有 4 种不同的环境——从开发到生产以及介于两者之间。这些环境有许多配置，因环境而异；然而，在我目前能想到的所有情况下，组件之间的依赖关系不会因环境而异，尽管我可能遗漏了一些东西和/或这显然会改变。

所以，最终的问题是，有没有人有使用 IoC 框架的类似经验？或者，任何人都可以推荐一个框架而不是另一个框架，它可以通过某种约定或简化的配置信息提供灵活的注册？我是否仍然能够从流畅的界面中受益，或者我是否坚持使用 XML——我想避免 XML 地狱。

编辑：这是一个 .Net 环境，我一直在研究 Windsor、Ninject 和 Autofac。它们现在似乎都支持两种注册方法（fluent 和 XML），尽管 Autofac 对 lambda 表达式的支持似乎与其他方法有点不同。有人在类似的多部署环境中使用它吗？

在参加了最近关于 IoC 的 Alt.NET 小组后，我开始思考可用的工具以及它们如何工作。 特别是使用属性和引导程序概念来映射对toStructureMap的请求。属性会自动为我抛出反射或 IL 注入正在进行的标志。有谁知道它是如何工作的（对于或其他 IoC 工具）以及在运行时或编译时相关的开销可能是多少？IThingConcreteThingStructureMap

我知道如何告诉 Castle Windsor 使用 XML 解析来自工厂方法的引用，但我可以通过 Container.AddComponent() 接口以编程方式完成吗？如果没有，还有其他方法可以从代码中做到这一点吗？

编辑： 似乎有些混乱，所以让我澄清一下，我正在寻找一种在代码中执行以下操作的方法：

（来自这篇关于 Windsor 和 spring.net 工厂支持的 codebetter 文章）

背景：在我的公司，我们正在开发一堆使用相同核心 dll 的应用程序。这些 dll 使用 Spring.net 的 IoC 容器来连接（自动连接）。所有应用程序都使用相同的 spring 配置文件，并且该配置文件指向许多不同 dll 中的许多类。但并非所有应用程序都需要每个 dll 的功能。但是由于 IoC 容器的工作方式，所有的 dll 都为 Spring.net 加载以检查类型并检查它们实现的接口等等。

核心问题：我知道最好只加载您真正使用的dll。但是仅仅加载一个托管的dll对内存使用真的很糟糕吗？还是首先您在 dll 中使用类，并且它们正在 JIT 中使用最多的内存？

I've got a solution with several different projects in it, some are pure class libraries and some are web app projects. If I want my default types to be available to all projects, where should I put the config file for the container?

我有一个实现 IDisposable 的对象，该对象在 Windsor Container 中注册，我想处理它，因此调用它的 Dispose 方法，下次调用 Resolve 时它会获取一个新实例。

做

立即自动调用 Dispose()？还是我需要做

在文档中找不到任何关于 Release 究竟是做什么的

编辑： 有关我运行的测试结果，请参阅下面的答案。现在问题变成了，如何强制容器释放具有单例生命周期的组件实例？这只需要在一个地方完成，编写自定义生命周期似乎太重了，没有内置的方法吗？

在 Windsor IOC 容器中是否可以注册我已经获得实例的类型，而不是让容器创建它？