使用 IoC 容器时要避免哪些事情？答案

【问题标题】：What are the things to avoid when using a IoC container?使用 IoC 容器时要避免哪些事情？
【发布时间】：2009-07-04 02:44:00
【问题描述】：

我是第一次在架构中引入 IoC 容器。我正在寻找一个不应该用 IoC 容器做的事情。我想避免使用 IoC 容器的陷阱。我不想滥用或过度使用它。

你能帮我列出使用 IoC 容器时要避免的事情吗？

到目前为止，我的清单上有一个项目：

不要让每个类都访问容器（不要将其设为公共 Singleton）。只有少数顶级类可以访问容器。

【问题讨论】：

标签： inversion-of-control

【解决方案1】：

也许这比您正在寻找的建议更简单，但我的建议是：不要挂在容器上。

IoC 是关于容器的 1%，关于内部组件的 99%。它们赋予了应用程序价值——另一方面，容器是基础设施垃圾；）

您应该能够以最有效的方式为您的应用程序设计这些组件。

如果您从看起来不错的容器开始，并且可以轻松创建封装良好、干净、自然且不严重依赖容器 API 的组件，那么您就走在了正确的轨道上。

但是，如果您发现自己为了将设计融入容器而费尽心思，并且您认为问题不在于您的设计，请立即找到一个没有影响您的限制的容器，然后继续前进前进。

希望这会有所帮助！

尼克

【讨论】：

【解决方案2】：

如果您要建立 IoC，我建议您查看 http://docs.codehaus.org/display/YAN/IoC+Container

这里有几个有趣的点

最明显的一个，容器不应该需要业务对象由它组装以实现任何接口，继承任何类，调用任何 API。这避免了直接对容器的依赖。

容器不应要求业务对象符合任何编码约定，例如“你有公开公共构造函数”，“你必须公开 Java Bean 设置器", “你必须有一个名为的方法 injectXXX", "你必须使用一个特殊的注释”等。这样的限制隐含依赖于容器，因为程序员业务对象仍然必须是了解该做和不该做的事容器。

不依赖任何 IoC 容器 API 在您的 IoC 对象中。这是一场悲剧违反 IoC 原则使用 IoC 容器。

IoC 容器用于装配对象的代码一起;这是为了配置系统的。毕竟不是用于业务对象。

最好使用声明式 API。公开声明式 API 比公开需要过程编码的 API 更好。

【讨论】：

Amazedsaint: 1 - 哪些 IoC 容器库不需要类符合某种约定？那么他们如何找到你的“注入点”呢？ 2 - 你能解释一下“声明式 API 更可取”是什么意思吗？使用其他类型的 API 会有什么缺陷？

【解决方案3】：

我想说不要使用配置文件来注册类型，除非你绝对必须这样做。它使重构变得困难，并且使用默认（非模拟）映射进行单元测试也变得更加困难。

【讨论】：

嗨 NotDan，为什么使用默认映射很难进行单元测试？
（至少对于 .NET）您的测试项目的配置文件与应用程序配置文件不同（即 MyApp.exe.config 与 MyTest.exe.config）。由于您没有使用实际使用的映射进行测试，因此您不能仅仅因为您的测试通过就确定您的应用会按预期运行。

【解决方案4】：

IoC 容器。

不，说真的；开始在没有 IoC 容器的情况下编写所有内容。一旦您掌握了 IoC 的工作原理并开始在您的代码中使用它，您就会开始看到容器可以提供帮助的领域。那是您应该添加容器的时候：当您准备好解决容器的实际问题时。不要仅仅因为有人说容器是好主意™而使用容器。

【讨论】：