Rubydependency injection库

我一直在寻找一些Rubydependency injection库。 特别是,我检查了Needle和Copland 。 他们已经存在了很长一段时间,但并没有很多用法。

使用这两个库有哪些优点和缺点? 看起来好像很多库/框架都可以很好地利用这两个库,例如Merb / Datamapper的Hook 。

编写Copland和Needle的Jamis Buck 在这里发布了有关Needle,dependency injection以及它们在Ruby世界中的用处的信息。

它很长但值得一读,但如果您想要与您的问题最相关的单个段落,我会在结束之前建议这个:

DI框架是不必要的。 在更严格的环境中,它们具有价值。 在像Ruby这样的敏捷环境中,并非如此。 这些模式本身可能仍然适用,但要注意陷入困境,认为你需要一个特殊的工具来应对一切。 Ruby是Play-Doh,请记住! 让我们保持这种方式。

HTH

http://fabiokung.com/2010/05/06/ruby-and-dependency-injection-in-a-dynamic-world/ :这是另一篇比詹姆斯巴克文章更不自然的文章。 最重要的是你不需要dependency injection,因为ruby提供了许多很好的替代方案,它们同样有效,并且在Java世界中并不存在。

其中一个替代方案是mixins,这是Java没有的东西,另一个是能够覆盖/重新定义语言中的任何东西。 其他function包括动态类型,基本上你可以向任何对象发送任何消息,如果碰巧提供该消息的实现,事情就可以了。 所有这些共同努力消除了对DI框架的大部分需求。 这样的设计模式在Ruby中仍然有效,有时使用它也是有意义的。

Alexey Petrushin上面提到的另一个关于DI的观点是,dependency injection主要是一种设计模式,工具是次要的,主要是为了摆脱Java中某些东西的繁琐。 在ruby中,你可以通过Java轻松模仿spring或guice为你做的大部分事情。 因此,完整的dependency injection框架在Ruby中基本上是多余的。

话虽这么说,有时候有一个DI框架是很好的,因为最终它可以带走一些繁琐的连接东西。 我不能保证任何Ruby特定的DI框架,但我知道很多Ruby项目最终用另一种语言(Java甚至)重写,因为事物的性质使得事情变得难以维护/扩展。 我怀疑这与开发人员用各种强大的语言function在脚下拍摄有很大关系。 有一个DI框架强加了一些结构和习惯用语可能有助于防止这种情况。

这里还有一个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