The Fat Controller

In the wonderful "Railway Series" of children's books by the Rev. W.V. Awdry there is an officious character named "The Fat Controller". He is in charge of the railway and is often involved in activities that perhaps would have been better delegated. So, moving on many years and I have embraced the MVC architectural pattern (from my early Smalltalk times) and am actively involved in building a web application that uses Rails.

My own history is that I tend to work outwards from the model - after all the domain is where the interesting rules are enforced, and I can figure out how to implement those without stretching my lousy artistic design sense. After all who needs more than a command line to test a domain model?

Taking this inside out approach certainly isn't typical in many of the Rails books that I have been reading of late. I see crazy statements from "experts" like "the only things that are models are wrappers for ActiveRecords" If it doesn't inherit from ActiveRecord it should not be in the Models directory. So where do these soi-disant experts recommend putting such logic? Ahhh, in the Controller of course. How they reconcile that with DRY (Don't Repeat Yourself) principles defeats me. Oh, and what if we want several different ways of receiving and managing the same data (maybe a b2b feed, an email message, a web form, a tweet, a txt message, an iphone app...), where should that logic reside.

The cognoscenti imply that there should be a single controller for this, so we now have a soup of concerns not a separation of concerns. Putting all the above into a single controller results in creating a Fat Controller of whom the Rev. W.V. Awdry would be proud.

Just say no to fat controllers

Controllers don't have to be activated by views.
Models don't just wrap active records
We don't want fat controllers gumming up the works with their officiousness.

Sir Topham Hatt, please don't teach my controllers to become overweight!