使用IoC容器时要避免哪些事项？

Question

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

您可以帮我列出一些使用IoC容器时要避免的事项吗？

到目前为止，我的列表上有项目：

• 不要让每个类访问容器（不要让它成为公共单例）。只有少数顶级类应该访问容器。

Answer 1

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

IoC对于容器是1％，对于内部组件是99％。它们是赋予应用程序价值的东西 - 另一方面，容器是基础设施垃圾;）

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

如果你从一个好的容器开始，并且没有创建完全封装，干净，自然的组件，而不是很大程度上依赖于容器API，那么你就是在正确的轨道上。 / p>

然而，如果您发现自己跳过箍以使您的设计适合容器，并且您认为问题不在于您的设计，那么立即找到一个没有影响您的限制的容器，并继续移动前方。

希望这有帮助！

尼克

Answer 2

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

以下是一些有趣的观点

  

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

• 容器不应要求业务对象符合任何要求   编码惯例，例如“你有   暴露公共构造函数“，”你   必须公开Java Bean setters“，   “你必须有一个名为的方法   injectXXX“，”你必须使用特殊的   注释“等。这种限制   放置一个隐含的依赖   因为程序员的容器   业务对象仍然必须   意识到这是做的，而不是从   容器

  

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

  
• IoC容器   是用于汇编对象的代码   一起;它是为配置   系统的。毕竟，事实并非如此   对于业务对象。
  
• 声明性API更可取。公开声明性API而不是需要过程编码的API是很好的。
  

Answer 3

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

Answer 4

IoC容器。

不，认真；开始编写没有IoC容器的所有内容。一旦掌握了IoC的工作原理并开始在代码中使用它，您将开始看到容器将在哪些方面提供帮助。那就是您应该添加容器的时间：准备解决容器的实际问题时。不要仅仅因为有人说容器是一个好主意而使用容器。