问题标签 [inversion-of-control]

谁能准确解释策略模式与控制反转的关系？

是否可以使 WCF 运行时通过 IoC 容器而不是通过其通常的过程来实例化服务？（另外，考虑到容器的类型的生活方式配置和服务的 InstanceContextBehavior 之间的潜在冲突，这种方法会是一个糟糕的主意吗？）

我知道我可能完全问错了问题。我的目标是通过容器提供的方法拦截工具实现 AOP 方法（例如，方法进入/退出日志记录、性能计数和调用限制，所有这些都涉及我不想插入到我的服务实现中的逻辑和依赖项）。我想 WCF 提供了其他方法来解决这个问题，所以我也很想听听其他推荐的方法。

IOC 容器何时处于 ASP.NET 应用程序的生命周期中？

我什么时候可以开始从容器中请求对象？

IOC 容器应该包含哪些最重要的功能？您可以在15 行代码中轻松创建容器，但它应该包括哪些内容才能在项目中“有用”呢？

与其他 IoC 容器（Windsor、Spring.Net、Autofac ..）相比，使用 Enterprise Library Unity 的优缺点是什么？

我正在尝试找出 Windows 工作流基础的内部结构。因此，我们有一些软件组件，我们以工作流的形式将它们交织在一起，无论是基于条件的顺序工作流还是状态机工作流。现在，我在想（我在这里可能错了）这并不同样适用于 IoC + 依赖注入（通过 Unity 或 Spring.net）。什么时候用什么？？我想对了吗？？

我最近阅读了Ayende 关于使用 XML 配置进行自动注册的博客文章。我想做他所做的，但他的代码片段对我不起作用。我的容器对象上不存在 Register 方法。

这是他的代码：

是否有我缺少的 DLL 参考？Register() 是扩展方法并且我没有引用正确的命名空间吗？我查看了 Castle Docs，但似乎找不到解决方案。

哪个 IoC 容器最容易上手。这可能等同于哪些文档拥有最友好的文档。不太担心功能的数量。

我正在使用 Castle Windosr 容器。我希望能够在运行时指定一些构造函数依赖项，这显然可以通过使用带有字典的 Resolve 重载来完成，一切都很好。但是，如果我想为根的依赖项指定运行时依赖项，那么我迷路了，目前我已经通过显式创建每个项并将其嵌入来解决。本质上它是一个装饰器场景，我想获得一个实例decator，同时在运行时为正在装饰的对象提供依赖项。有任何想法吗？我宁愿不必做我在下面做的事情，也不想让 decarator 构造函数填充下面的对象，因为有时依赖项会不一样。

在 Microsoft Unity 中，您可以从现有 XML 配置配置容器，但有没有相反的方法？从初始化的容器导出相应的 XML 配置？