#skinnycontrollers

First things first, a big shout out to both the folks over at Code School and our head honcho here at Barbershop Labs, señor Adam Rubin, for imparting some of their Rails wisdom to me.  And without further adieu...

An exclusive peek inside of the Barbershop Labs offices.

The basics:

A couple of mantras every Rails programmer hears chanted from the very earliest stages of his or her career are to keep your code DRY and Convention Over Configuration.  

The first is Don't Repeat Yourself for ye uninitiated, and at its core it is about keeping your code encapsulated in reusable methods/functions, classes and modules.  Identical or highly similar functionality then only need to be edited in one place in order to cascade changes throughout your entire application.  Furthermore, giving semantic names to these snippets of code helps to keep your code readable for others.

The second, Convention Over Configuration, refers to architecting your application so as to follow established file structures, design patterns, and code formatting in order to, much like DRY, make your codebase easy for others to understand, debug and expand upon.

The Rails Way:

As you become more well-versed in Rails it becomes apparent that there is a lovely union between these two concepts.  Rails encourages you to keep your code DRY in very specific (read: conventional) ways, expanding on the framework-agnostic approaches of extracting code into methods, classes and modules, and providing specific guidance on how to keep an MVC application maintainable and extensible.  Beware!  What follows is certainly not an exhaustive guide on what is considered best practice in Rails.  But it is your humble author's hope that this discussion on single-responsibility models and controllers, as well as the topics covered in DRY'ing Out Your Rails App Part 2, can serve as a good primer for those looking to get a little cozier with "the Rails way" of doing things.

Skinny Controllers and Skinny Models, Too:

A center for ants?

Ensuring that your controllers and models (which are simply classes) follow the single responsibility principle, that all classes should have a single coherent purpose and only a single reason to change, is an important step towards keeping your code modular and easily understood.  Instead of striving for "skinny controllers and fat models" your approach should be to make both models and controllers lean, mean adherents to SRP.

For controllers, this means restricting your methods to the seven standard Rails CRUD actions, index, show, new, create, edit, update and destroy, in all but extraordinary circumstances.  Most any Rails developer will tell you that the responsibility of the controller is essentially to dispatch incoming requests to the appropriate views, referencing the appropriate data and business logic from models.  But many a Rails developer (as I guiltily look in the mirror) have strayed from that path by adding actions which belong either as business logic in a model, or in an entirely new controller.  

For example, complex or unusual functionality with your registration process may require both a Users and Registrations controller.  A controller that makes frequent use of non-business logic conditionals or that makes use of non-CRUD actions could likely stand to be split out into two separate controllers, each with a clear, single responsibility.

The more common scenario requiring cleanup in a controller is extracting business logic into your models (frequent use of business logic conditional statements in the controller is typically an indicator that this needs to be done) in the form of instance methods (sometimes called guard clauses in this context) or callbacks such as before_save, after_save, after_destroy, etc.  But the process of ensuring that your controllers and models obey SRP is not always as simple as shifting code from one to the other.

As with controllers, it is best practice to separate functionality out into two models if that creates a clearer, more modular purpose for that class.  The previous example of a complex user registration process could again apply to your models.  So, rather than one large model, full of logic for altering the state of your Users, you might have two.  One that deals specifically with registration, and another for the remaining logic.  

Continuing with the registration example, the registration model does not need to inherit from ActiveRecord as it can act simply as the User model's interface for logic pertaining to registration by taking an instance of the ActiveRecord model as an argument (example below).  This makes the Registration class significantly more lightweight (because ActiveRecord is, in technical terms, a Bad Mamma Jamma), and creates even more clearly defined encapsulation:  one model encompasses a specific set of business logic, while another interfaces with the database via ActiveRecord.

Well friends, that's all for today.  Coming soon:  Part 2, where we'll discuss Concerns, Scopes and Decorators.  Thanks for reading!