IoC 容器适用性/场景演示？答案

【问题标题】：IoC Container Applicability / Scenario Demonstration?IoC 容器适用性/场景演示？
【发布时间】：2008-11-19 19:40:07
【问题描述】：

.NET 领域的很多人都选择了 Castle Windsor 并在他们的项目中实现它，在过去的一年里，我一直在努力弄清楚为什么 IoC 容器似乎被视为一般的“最佳实践” “？我已经阅读了很多关于温莎之类的原因的摘要和简要解释，但每一个都确实是抽象的，对于我接触过的大多数项目来说似乎并不实用，但最近我一直遇到很多使用 Windsor 的项目，我不明白为什么。

C#/.NET 固有地支持基于接口的编码、抽象对象、委托和事件。可以直接从核心语言实现 IoC，并使用反射等实例化实现已知接口的未知实例，而无需求助于 IoC 容器库。

在应用 YAGNI/AYGNI（你会需要它吗？）时，我觉得温莎被过度使用了。我当然可以看到 IoC 容器的好处，但我认为这些好处是以额外的依赖项和元数据为代价的（核心代码中调用的 IoC 容器特定属性和方法、分散在各处的 .config 文件、app.config/web.config填充了绑定标签，使 .config 文件更难编辑等）所以我试图找出权衡。

也就是说，我接受这样的可能性，即我将这些观察/陈述中的所有都归咎于无知，因为我从未大量参与过使用 Windsor 或其他 IoC 容器的项目图书馆。我真正需要的是让某人演示一个使用 IoC 容器库的“平均”或“典型”项目，以及为什么这应该是“最佳实践”，而在我看来，这会让原本干净的项目变得混乱包含依赖项和元数据。

如果有人知道任何可以填满我的博客文章、文章或书籍，那就太好了。

（我不是为了争论而争论，而是因为我真的很想接受关于我是否应该在 IoC 容器方面自学的教育）。

【问题讨论】：

标签： castle-windsor ioc-container

【解决方案1】：

好像你想要this question的答案

显然，如果系统像您所说的那样难以设置，那么在您维护它时它就没有多大价值了。在使用新技术时要牢记这一点。有时，仅仅因为这个因素，旧的无聊东西会更好。

Castle Windsor 本身使用反射，因此它确实是一个包装器，可以按照您想要的方式做事。如果您可以开发一个比 CW 更易于使用的系统，那么您应该这样做，即使它在初始启动时间上花费了您。这个成本首先会被 CW 的学习曲线所抵消，所以不会像重新发明轮子一样。

他们确实say themselves说IoC不适合小项目，

另外，取决于大小和项目的复杂性，IoC 容器可能是矫枉过正。较喜欢在大中型项目中使用它。

【讨论】：

【解决方案2】：

这不是您问题的直接答案，因为我不熟悉 Castle-windsor，而且我不是 IoC 专家，但根据我对 Spring 的 java 版本的经验，我可以说（我是在这里谈论春天，所以城堡温莎可能不是这样）不仅仅是依赖注入部分，还有框架本身：声明式事务管理、内置安全框架、ORM 支持、内置 MVC Web 框架、RMI、Web 服务、Email、AOP 等。它与 IoC 很好地集成在一起，框架确实为大多数典型场景做了很多工作。

我认为使用注释自动装配 + IDE 支持（例如 IntelliJ IDEA for Spring）可以缓解配置文件问题。

我不知道 Castle-windsor 是否是 IoC 容器之外的任何东西，但如果是的话，就其作为框架的丰富功能而言，它可能还不存在。

【讨论】：

【解决方案3】：

我不一定相信 IoC 容器在所有情况下都是好的。但绝对可以。如果您使用依赖注入或服务定位器来处理依赖关系，那么无论如何您已经走了很长一段路，但是 IoC 容器可以帮助您自动执行操作，为您提供对更高级场景的支持等。

不久前，我试图在一篇博文中为自己定义它：

控制反转 (IoC) 容器是一种非侵入式可配置智能工厂组件

将这个定义分成几部分，我们得到

工厂，因为它负责为你创建对象。
智能，因为它了解您拥有的依赖关系，并递归地为您创建它们。
可配置，因为你可以通过代码或配置文件来配置使用。
非侵入性，因为使用的对象不需要知道容器。

-

如果您将它与依赖注入或服务定位器模式一起正确使用，您确实会获得一些非常方便的好处。您不一定需要使用像 Winsor 这样的外部容器，但这确实会给您带来一些额外的好处。

您可以编写更少的代码来实例化新对象。如果您想到更复杂的对象层次结构，IoC 容器可以帮助您自动创建整个链。这可能非常强大。

您可以在测试期间轻松添加对象的模拟版本而不会出现问题（如果您使用 DI 和/或 SL）。例如，为自己创建一个服务定位器也可以解决这个问题。

改变你想在构造函数中注入的依赖并不一定意味着你需要重构很多代码。

您可以通过一个来源获得隧道依赖项的各种好处：装饰器、拦截器、代理，以及处理对象的生活方式。使用像 Windsor 这样的容器，这使您能够非常简单地完成一些困难的事情，并且耦合极少

您可以将其设施概念与 NHibernate 平滑集成

【讨论】：

【解决方案4】：

我建议您收听 Software Engineering Radio 播客的第 2 集。这是关于依赖注入的一整集。依赖注入是控制反转框架最广为人知的用法。我还建议听听 John Kovacs 的 DotNetRocks 第 362 集。 Here 是节目的抄本。

现在，IOC 的一个副作用是提高了可测试性。像 Castle Windsor 这样的 IOC 容器的使用有助于解耦依赖关系。这种解耦有助于更好的单元测试。

大多数 IOC 框架还带有促进面向方面编程的方法。因此，如果您喜欢 IOC 容器框架，可以帮助您。

【讨论】：