IoC / DI is still alive (new release of Micon DI)

Ruby
1

New release of Micon DI - silent killer of dependencies and configs.

http://alexeypetrushin.github.com/micon

I know that in Ruby world Dependency Injection is not very popular, but
Micon isn’t like classical DI, because:

  • it’s very simple
  • most of time it’s invisible and works silently

And, I believe that the one of the reasons DI aren’t very popular in
Ruby is because some of Ruby DI are 1-to-1 clone of Java DI, and because
Java != Ruby there are some problems with this approach ( more details
here http://ruby-lang.info/blog/you-underestimate-the-power-of-ioc-3fh
).

I’m also using it as the kernel of this site http://ruby-lang.info ( You
can see its sources here https://github.com/alexeypetrushin/rad_sbs )

Hope it may be usefull in some of Your projects.

2

http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-programming

3

I watched this talk, and I’m agreed that there’s no need in AOP technics
provided by DI - because Ruby is dynamic language and has
metaprogramming capabilities that are way more powerful and handy than
DI AOP.

But I disagreed with the conclusion out of this fact - that there’s no
need for DI in Ruby. Because AOP is only one aspect of DI, and although
You don’t need AOP, You may benefit from others capabilities.

No matter how Your code looks like - lots of Lego building blocks (Java)
or free-design with plasticine, You has to solve following problems:

  • where the component’s code is located.
  • in what order should it be loaded.
  • what configs does the component needs to be properly initialized.
  • where those configs are stored.
  • how to change configs in different environments (dev/test/prod
    database settings, routes, …).
  • where are dependencies for component and how they should be
    initialized.
  • how to replace some components with custom implementation (without
    examining its code and monkey-patching).
  • how to assembly parts of application for specs/tests.
  • how to restore state after each spec/test (isolate it from each
    other).
  • how to control life-cycle of dynamically created components.
  • connecting components to assemble an application.

DI simplifies these tasks and some of them solves completely
automatically.

And if You think that You don’t need any structure and want complete
freedom - why do You use Rake?
It limits Your freedom to work with the Ruby plasticine and introduce
extra abstraction, so why do You use it?