DI Sample

product_controller.rb

class ProductController < ApplicationController

  def index
    @products = Product.all
  end

end

ProductController.cs

public class ProductController : Controller
{
    private IProductRepository _productRepository;

    public ProductController(IProductRepository productRepository)
    {
        _productRepository = productRepository;
    }

    public ActionResult Index()
    {
        products = productRepository.getAll();
        return View(products);
    }
}

One other note:

So in the C# we're not dependent on Product (just on anything that is iProductRepository) and in the Ruby, we are.

I'd disagree with this, but only because of my insider knowledge knowing the code sample that's in my head. 😄

If I have a C# method call like this:

productRepository.getAll()

that method has to return something, and in most cases with will be this:

IEnumerable<Product>

The dependency on Product still exists. It's a concrete type, sealed up in a DLL along with everything else that's there.

Why does this matter? Because I want to blow @hotgazpacho 's mind... I sometimes have tests written like this:

describe "index" do
  it "should pass the products to the view" do
    products = Object.new
    Product.stubs(:all).returns products
    controller.index
    controller.instance_eval { @products }.must_be_same_as products
  end
end

To me, this illustrates the real nature of Product.all, and how it differs from the C# example. Product.all, indeed, a method on a Product, but within our code it's more of that (2) I mentioned above. It's our way to get the products, no matter what they might be... and we leave it to the outside world to define what that way is. This is much different that the C# example, where ALL of the dependencies of the interface are brought to bear as soon as I reference it.

Of course, with this great power comes great responsibility. ⚠️

Heh. Sorry to disappoint, @darrencauthon, but my mind remains intact. That Ruby example is pretty much exactly what I had in mind 😉

Question for you, though, @darrencauthon. Does calling controller.index like that, as opposed to the more common apraoch of using the TestRequest class, still invoke the before/after/around filters for the action?

@hotgazpacho It does not call the filters... but that's what I want! I want to be able to unit test the controller action in isolation from anything else.

I am a rare bird 🐦 as I use Rails yet I unit test my code. I know there are debates about unit testing versus integration tests, but to me -- without unit tests, I can't TDD, and if I can't TDD I'm not able to architect and verify my output.

I also use few filters.... if things get complicated, I'll string an integration test through them. But if things are complicated, I'm doing something else wrong. 😆

This may be a perfectly good way to code it, and to test it. It's simple, I like it, and it'll probably do just fine. IMO, however, it is not Dependency Injection, simply because there is no injection going on.