Ruby-based injection libraries

I studied some Ruby-based injection libraries. In particular, I checked Needle and Copland . They have been around for quite some time, but not many customs.

What are some of the pros and cons of using these two libraries? It seems that many libraries / frameworks can make good use of these two libraries, for example. Merb / Datamapper Hook .

+25
ruby dependency-injection aop
Nov 12 '08 at 9:58
source share
3 answers

Jamis Buck, who wrote Copland and Needle, has posted here about Needle, dependency injection and its utility in the Ruby world.

It's a long, but worth reading, but in case you want one paragraph to be most relevant to your question, I would suggest it from the very end:

DI structures are not needed. More harsh environments, they have value. In flexible environments such as Ruby, there are not many. The samples themselves may still be applicable, but beware of falling into the trap, thinking that you need a special tool for everything. Remember Ruby - Play-Doh! Let's continue this.

NTN

+46
Nov 12 '08 at
source share

http://fabiokung.com/2010/05/06/ruby-and-dependency-injection-in-a-dynamic-world/ : this is another, much less stubborn article than James Buck's article. The bottom line is that you donโ€™t need dependency injection because ruby โ€‹โ€‹provides many good alternatives that work just as well and which actually don't exist in the Java world.

One of these alternatives is mixins, which Java does not have, and the other is the ability to override / override anything in the language. Other features include dynamic typing, in which you can send any message to any object, and if this happens to ensure that this message is implemented, everything will work. All of these things work together to eliminate most of the DI infrastructure need. The design template as such is still valid in Ruby, and sometimes it makes sense to use it.

Another point that Alexey Petrushin talks about is that dependency injection is primarily a design pattern, and the equipment is secondary and basically eliminating the tediousness of some things in Java. In ruby, you can trivially emulate most of what spring or guice is for you in Java. Thus, the full-blown dependency injection infrastructure in Ruby is significantly redundant.

Saying this, sometimes having a DI framework is enjoyable, as it can ultimately take away some of the wiring of wiring. I cannot vouch for any Ruby-specific DI framework, but I know many Ruby projects that ended up being rewritten in another language (even Java), because the nature of the playdo-style game makes it difficult to maintain / extend. I suspect this has a lot in common with developers shooting in the foot with various powerful language features. Having a DI framework imposes a bit of structure and idioms that can help prevent this.

+6
Oct 31
source share

Here's another IoC http://alexeypetrushin.github.com/micon

I used it as the main component of my web structure (not Rails), you can see that it works here - http://ruby-lang.info (this is the site with it). And it saved me a lot of time and code, so I personally find IoC very useful (in some situations).

DI structures are not needed. In more severe conditions, they have value. In flexible environments such as Ruby, there are not many. The samples themselves can still be used, but beware of falling into the trap of thinking that you need a special tool for everything. Remember Ruby - Play-Doh! Let's keep it that way.

I watched the talk about Jamis Buck and I agree and disagree with him, thatโ€™s why http://ruby-lang.info/blog/you-underestimate-the-power-of-ioc-3fh

+1
Jun 17 '11 at 18:38
source share