In Rails, shouldn't we create a service layer, instead of jumbling logic into a controller?

Question

Say I have a controller that returns a list of users. The users are to be returned from memcache if the cache key exists, otherwise hit the mysql db. This logic will be re-used in say a web service layer or something.

action:

def list

  if in cache
     @userlist = ...
  else
     @userlist = User.all()
  end

end

In the Java world, you would create a UserService layer that would wrap additional logic (like first checking the cache layer, etc.).

In rails it people tend to put all this logic in the controller.

What is the Rails 'best-practise' here?

Answer 1

There seems to be a "small" movement in the Rails community to establishing a service layer in some projects/applications. In 2010, I worked on a project where we introduced a apps/services directory to store service objects. We found that the application logic was spread across controllers and models and this helped encapsulate such behaviour. James Golick has an interesting post on the subject. Check out Pat Maddox's comments as well:

http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome-the-way-i-write-rails-apps.html

Answer 2

The "Rails way" is: skinny controllers, fat models.

You can simply change the model to support cache:

class User < ActiveRecord::Base
  def self.all
    @cached[:all] ||= super
  end
end

Or create an injector to support cache the way you want for multiple models:

class User < ActiveRecord::Base
  include CacheInjector
end

Remember: Ruby, as a dynamic language, is very easy to extend. Mixins, interceptors, aspects, all those things that are a PITA to implement in Java, are very easy and natural on Ruby. Give it a try.