Lets talk about responsibility for a moment. In my opinion, if it's an interaction, it shouldn't belong to one specific model. What if you need a send_invoice_email to go with send_welcome_email? This can quickly get out of hand. This is why I use service objects.

So what exactly is a service object? It's really just an object that encapsulates operations. Using our initial callback example, lets refactor it to use a service object by adding the following to app/services/send_welcome_email.rb

Implementations

If you've read other articles on service objects, you've probably run into multiple implementation methods. Some developers advocate that a service object should only respond to call, and only perform a single task. I don't see a reason for being so nitpicky. Instead, my service objects encapsulate related responsibility. For example, integrating with a third-party service:

I constantly find a need for default values in my ActiveRecord models. Many people recommend database migrations for this, but unless it's for counters, I try to keep it application side. A common approach is to use an after_initialize call:

classAccount<ActiveRecord::Base# After initialization, set default valuesafter_initialize:set_default_valuesdefset_default_values# Only set if time_zone IS NOT setself.time_zone||=Time.zone.to_sendend

This is a standard ActiveRecord callback that gets called both when an object is instantiated and when retrieved from the database. Be sure to set the value conditionally, as you don't want to overwrite the value when it's pulled from the database.

I'm sure we can clean this up a little using ActiveSupport::Concern. Concerns are very similar to standard Ruby modules, but with some added (and semi-controversial) functionality. All we need to do is add the following to app/models/concerns/defaults.rb:

moduleDefaults# Added to instance of objectincludeddoafter_initialize:apply_default_valuesend# Callback for setting default valuesdefapply_default_valuesself.class.defaults.eachdo|attribute,param|nextunlessself.send(attribute).nil?value=param.respond_to?(:call)?param.call(self):paramself[attribute]=valueendend# Added to class of objectclass_methodsdodefdefault(attribute,value=nil,&block)defaults[attribute]=value# Allow the passing of blocksdefaults[attribute]=blockifblock_given?enddefdefaults@defaults||={}endendend

Including this file does the following:

Adds a default method for assigning mappings

Adds a defaults method for returning mappings

Defines a callback which iterates over the mappings and assigns the default values.

Using this concern is as simple including it into your model and calling default on the attribtues you want to have a default value.

classAccount<ActiveRecord::Base# Include the concernincludeDefaults# We can define heredefault:time_zone,Time.zone.to_s# Or pass a blockdefault:time_zonedoTime.zone.to_sendend

Not only is this simple to implement, utilizing concerns will DRY up your code. Just remember, if you're using a concern in only one model, there really isn't a reason for it.

I'll be honest, I'm not a fan of Rails helpers. There's something about poluting a global namespace with unorganized cruft that makes me twitch ever so slightly. How do we get away, or at least minimize the usage of helpers? Simple, we use a decorator. A decorator allows you to add additional functionality to an object without it deviating away from it's core responsibility. A quick search of Github yields many decorating systems, the most noteable being Draper. I've used Draper and think it's a fantastic library, but for me it feels a bit cumbersome for my needs. This is why I created Decco.

Decco is a combination decorator/presenter system. It's designed to be lightweight and simple to use, built off simple Ruby classes. All you need to do is create a class that takes an object to be decorated when instantied. For example:

# Infers name from object -- UserDecoratorDecco.decorate(@user)# Specify a decoratorDecco.decorate(@user,OtherUserDecorator)

If you're using this within Rails, then you get an additional helper for your views:

# Get a decorator singleton instanced(@object)image_tag(d(@user).gravatar_url)

This helper instanties the decorator with the current view object so you can call Rails helpers within your decorator.

Ultimately, Decco strives to be as simplistic as possible. It's merely a simple wrapper to instantiate your decorator/presenter based on the object as well as provide a simple helper for caching the decorate call.