3

By day I am a .NET ASP.NET MVC developer but by night I'm working on an e-commerce application built in RoR 3.1.

We are starting with one payment processor with the understanding that we'll be moving to another one in 6 to 8 months. I don't want to repeat code so if I were doing this in .NET, I'd create an interface and create a class to implement that interface. I'd create two classes for each payment processor and then just use dependency injection to specify which one to use like:

ninjectKernel.Bind<IPaymentProcessor>().To<PaymentProcessor1>();

and then when we switch all I'd have to do is change that one line to PaymentProcessor2.

Are there any tutorials you know about or code samples out there that would lead me down the same path for ruby on rails? I know ruby is dynamic and I won't need an interface.

Any guidance would be greatly appreciated.

Thanks!

Mike
  • 2,561
  • 7
  • 34
  • 56
  • 2
    Hi Mike, for what I've read in a few places, there's no need to use a DI framework in Ruby because of it's [dynamic nature](http://fabiokung.com/2010/05/06/ruby-and-dependency-injection-in-a-dynamic-world/). I'm not doing any commercial development with ruby, but I still feel a bit odd about the idea of not having a DI framework (I java a Java background). – Augusto Oct 14 '11 at 15:51

3 Answers3

2

Dependency injection is usually unnecessary with Ruby. Jamis Buck blogged extensively about the reasons why. Well worth a read.

John Topley
  • 113,588
  • 46
  • 195
  • 237
  • there is a rebuttal of this opinion referenced in this answer: http://stackoverflow.com/questions/283466/ruby-dependency-injection-libraries – hoffmanc Oct 11 '12 at 13:53
0

The general consensus is that while the DI pattern is relevant in Ruby, a DI container is not necessary.

Jamis Buck was underway with a DI framework called Needle, but later changed tack and stated that, while he uses the DI pattern every day, a container is simply not necessary, because "Ruby is plah-doh, while the Java, .NET and other languages that require a library to manage DI concerns are blocks".

This idea is very commonly misinterpreted that "you don't need DI in Ruby". Jamis' message was that a container is not necessary, just as its not strictly necessary in any language - but even more so in Ruby.

While the consensus is that a container is unnecessary there are quite a few out there. One notable is that of Jim Weirrich, the author of Rake and rspec. He created one called Dim, which stands for DI-minimal.

Jasper Blues
  • 28,258
  • 22
  • 102
  • 185
0

Take advantage of duck typing, which is part of the dynamic nature of Ruby. If both of your payment processor classes respond appropriately to the same methods that are used in your app, then you can interchange them freely. No DI framework necessary.

Wizard of Ogz
  • 12,543
  • 2
  • 41
  • 43
  • How is this different to using an interface in Java/.NET or pure virtual methods C++? If you hard-wire one class, you'd still have to go and change all the places its hard-wired to supply the other . . Dynamic-dispatch means an interface isn't really necessary (already implied), but this is not the same things as DI at all. – Jasper Blues Oct 11 '13 at 10:15
  • 1
    @JasperBlues I think you misunderstood my comment. I regularly use dependency injection in Ruby, but find that a _DI FRAMEWORK_ is unnecessary. In short, I was trying to say some of what you said and what John Topley alluded to. I wasn't trying to equate dynamic-dispatch with DI ;-) – Wizard of Ogz Oct 11 '13 at 16:51