ruby - Ruby 依赖注入库

Question

我一直在研究一些 Ruby 依赖注入库。特别是，我检查了 Needle和Copland。它们已经存在了很长一段时间，但用途并不多。

使用这两个库有哪些优缺点？似乎很多库/框架都可以很好地利用这两个库，例如Merb / Datamapper's Hook。

Answer 1

编写 Copland 和 Needle 的 Jamis Buck在这里发布了有关 Needle、依赖注入及其在 Ruby 世界中的用处的信息。

它很长但值得一读，但如果您想要与您的问题最相关的单个段落，我建议您从结尾开始：

DI 框架是不必要的。在更严格的环境中，它们具有价值。在像 Ruby 这样的敏捷环境中，没有那么多。模式本身可能仍然适用，但要小心不要陷入认为你需要一个特殊工具来处理所有事情的陷阱。Ruby 是 Play-Doh，记住！让我们保持这种状态。

高温高压

Answer 2

http://fabiokung.com/2010/05/06/ruby-and-dependency-injection-in-a-dynamic-world/：这是另一篇文章，比 James Buck 的文章少得多。底线是您不需要依赖注入，因为 ruby​​ 提供了许多很好的替代方案，它们同样有效，但在 Java 世界中并不存在。

其中一种选择是 mixins，这是 Java 所没有的，另一种是能够覆盖/重新定义语言中几乎任何东西的能力。其他功能包括动态类型，基本上您可以将任何消息发送到任何对象，并且如果它恰好为该消息提供了实现，那么一切都会正常工作。所有这些东西一起工作，消除了对 DI 框架的大部分需求。这样的设计模式在 Ruby 中仍然有效，有时使用它才有意义。

上面 Alexey Petrushin 还提出的关于 DI 的另一点是，依赖注入主要是一种设计模式，工具是次要的，主要是为了摆脱 Java 中某些事情的乏味。在 ruby​​ 中，您可以轻松地模拟 spring 或 guice 在 Java 中为您所做的大部分工作。所以一个成熟的依赖注入框架在 Ruby 中本质上是多余的。

话虽如此，有时拥有一个 DI 框架还是不错的，因为最终它可以消除一些繁琐的连接工作。我不能保证任何 Ruby 特定的 DI 框架，但我知道很多 Ruby 项目最终被另一种语言（甚至 Java）重写，因为事物的游戏性质导致事情变得难以维护/扩展。我怀疑这与开发人员使用各种强大的语言功能自欺欺人有很大关系。拥有一个 DI 框架强加了一些可能有助于防止这种情况的结构和习语。

Answer 3

这是另一个 IoC http://alexeypetrushin.github.com/micon

我将它用作我的 Web 框架（不是 Rails）的核心组件，您可以在此处看到它的工作原理 - http://ruby-lang.info（此站点由它提供支持）。它为我节省了大量时间和代码，所以我个人认为 IoC 非常有用（在某些情况下）。

DI 框架是不必要的。在更严格的环境中，它们具有价值。在像 Ruby 这样的敏捷环境中，没有那么多。模式本身可能仍然适用，但要小心不要陷入认为你需要一个特殊工具来处理所有事情的陷阱。Ruby 是 Play-Doh，记住！让我们保持这种状态。

我看了 Jamis Buck 的谈话，我同意和不同意他的观点，这就是为什么http://ruby-lang.info/blog/you-underestimate-the-power-of-ioc-3fh