Rails Misapprehensions: The Dependency Injection Pattern

{{{

Inspired by the “Stop hating Java”:http://andrzejonsoftware.blogspot.com/2011/07/stop-hating-java.html post by my friend Andrzej I started to identify the pros and cons of a pattern called _Dependency Injection_ in the Ruby/Rails world. Before I explain the pattern, let me discuss the problem – a dependency.

h3. What is a Dependency?

Let’s say we’re working in a casual Rails controller instance. Whenever we access an object (or class) instance different to the current controller instance (i.e. @self@), we’re creating a _dependency_. Dependency here means the controller needs to know class and method names in another domain. Here are some typical dependencies found in many controller actions.

def show
  @comments = Comment.find(:all)

Here, the action knows both _where_ and _how_ to find the comments. It’s a dependency to the model layer.

def update
  # ...
  logger.notice "Comment #{@text} updated."

In this example, we have a strong dependency to the logger component – looking into the Rails code we can see that the @#logger@ method in turn creates a logger instance, so we have to know about _instantiation_ and _usage_ of the logger.

%h1 Welcome, #{current_user.name}

This partial uses a helper method @#current_user@, which in turn queries controller and request in order to find the current user instance.

h3. What’s the Problem with Dependencies?

Now, the examples above are code you’re gonna find in almost any Rails application – and there’s nothing wrong with that! However, problems _might_ appear as soon as you want to *test components separately*.

For instance, what if I’d like to test my logging code within the controller, like asserting that the correct message is logged when something special happens?

it "logs correctly" do
  put :update
  assert_equal "Comment Yo! updated.", 
    @controller.logger.last_notice

I’d have to mock the logger instance to make it “testable”, here, to provide the @#last_notice@ method.

Let’s say the original @#logger@ method looks like this.

  def logger
    @logger ||= Rails::SmokeSignalLogger.new
  end

To mock the logger, people overwrite the respective method in the test case.

ActionController.class_eval do
  def logger
    @logger ||= Test::MockedLogger.new
  end

Code like this changes the logger for the entire test suite and might break other tests. A common solution is to _reset_ the original method after each test. In other words, *we change a global property for a local test* – and this is wrong.

h3. Another Problem: Configurability

In addition to the testing problems we get with dependencies, what if my colleagues love the way I program and plan to use one of my modules in their software (highly improbable). However, they don’t want the @SmokeSignalLogger@ since they’re not speaking Indian, but they want to use another logging layer @JungleDrumsLogger@?

As soon as my component is imported in their application they’d probably _monkey-patch_ my code to “configure” it.

NicksControllerMethods.class_eval do
  def logger
    @logger ||= 
      JungleDrumsLogger.new(:flavor => :coconut)
  end

I personally *consider monkey-patching a code smell*.

h3. What’s a component?

Ok. I showed a couple of examples about dependencies and I used the word _component_ a lot. The reason for this is: The Dependency Injection pattern is *only applicable in software systems consisting of separated components*. The idea is that outer components _inject_ dependencies into smaller components.

A component as it might be a _piece of software_ like a controller instance, an ActiveRecord row instance or a logger object. I see three attributes to make something a component.

* First, a component has a limited scope of interest. It’s field of work is bounded to some special duty (logging messages, rendering a comments box, …).
* Second, a component instance cannot access properties of other components, unless you’re providing a way to do so. For example, the logger may not access variables of the controller and vice-versa.
* Last, components are reusable and might be used in different systems in a way that the using system does *not* have to change _code_ on the imported component to make it work. I found this in “Martin Fowler’s excellent Inversion of Control post”:http://martinfowler.com/articles/injection.html.

h3. Dependency Injections in Rails

To get back to our examples, let’s see how we could apply DI to get rid of the logger dependency. Don’t let the controller create it itself, but do that on the outside and pass – “inject” – the object into the controller.

One flavor of DI is called _Constructor Injection_ and would imply we inject the logger in the constructor.

class ActionController < ...
  def initialize(..., logger)
    @logger = logger
  end

Obviously, the outer framework would have to take care of creating and passing the logger.

  logger = BushDrumsLogger.new
  controller = ActionController.new(..., logger)

A second form is called _Setter Injection_ where the controller exposes a writer for the injected attribute.

class ActionController < ...
  attr_writer :logger

Both the using frameworks or the test case can set the logger *without overriding any code at all*.

  controller.logger = TubeMailLogger.new

h3. Cells and DI

One huge problem I see with Rails and DI is: currently, *there are not enough components*. We got one monolithic ActionController instance, a couple of row models and a global view instance – that’s it. This doesn’t make Rails a bad thing, or thousands of well-running apps out there!

However, the missing components in Rails make it hard to write reusable software and test these in isolation. That’s why we got the “Cells gem”:https://github.com/apotonick/cells – it provides reusable view components for Rails and goes perfectly together with DI.

Say we have a sidebar widget that displays the recent comments from your blog. A cell encapsulates that part of the page, the data aggregation and the rendering (“read this post”:http://nicksda.apotomo.de/2010/11/lets-write-a-reusable-sidebar-component-in-rails-3/ if you need a quick introduction to Cells).

h3. Injecting the logger, ouch!

If we needed a special logging mechanism for the widget we could pass it into the component. I don’t know why a widget displaying comments would need to log, but let’s assume it.

%h1 My great blog

#sidebar
  = render_cell(:sidebar, :comments, logger)

The cell could then use the external logger without creating a dependency.

class SidebarCell < Cell::Base
  def comments(logger)
    logger.notice "Displaying comments at #{Time.now}!"
    
    render
  end

The additional arguments from the @#render_cell@ invocation are directly passed as method arguments – this is what we call “_state-args_ in Cells”:http://nicksda.apotomo.de/2011/02/cells-3-5-release-party-summary/.

It’s obvious that another project using that sidebar component *could _inject_ a completely different logger instance*.

}}}
{{{
h3. Testing with DI

The limited scope of a cell makes it pretty easy to test. Not only can we test that object-oriented “partial” in complete isolation but also can we pass in a mocked logger easily.

it "should render beautifully" do
  render_cell(:sidebar, :comments, mock_logger).
    should have_selector("ul")
end

it "should log correctly" do
  logger = ArrayLogger.new
  render_cell(:sidebar, :comments, logger)

  logger.last.should match /Logging/
end

No need to change or reset any global here, just throw-away instances and we’re done!

h3. Conclusion

I can’t think of a cleaner solution for dissolving dependencies like these. The DI pattern makes it easy to keep your components dumb. The problem is that you first have to *identify your dependencies, then refactor to components* and inject instances from the controller (or wherever else).

Especially in Rails, Cells help to build a real MVC application with a data-aggregating ActionController (“I call this _FrontController_”:http://nicksda.apotomo.de/2010/11/rails-misapprehensions-cells-dont-break-mvc/) and fine-grained view components that get additional dependencies from the outside.
}}}

Advertisement