Tomáš Pospíšek's Notizblock
Long time ago a few Ruby on Rails developers in my entourage claimed that business logic should be pushed down into the Model layer.
That didn't make hugely sense to me and since there's a lot of fandom in Rails where your status as a developer seems to be very strongly correlated to the number of the latest buzzwords and Rails extensions you're decorating yourself with and since the claim did not come along with a strong rationale either I pretty much dismissed it as yet another brain fart.
Today though I coincidentally stumbled over an article that very plainly, convincingly and succintly argued the case:
the Controller should concern itself with the handling of the arguments received from the outside world (possibly the user) and with choosing the right view to render the answer/result with.
unit testing any logic inside the Controller is painful and unrobust since the unit test will need to concern itself with output parsing.
a Model represents a business object and all the things you can and are allowed to do with it.
However that leaves a gaping hole: where are the business processes? The code thus, that juggles a multitude of different Models, checks them, changes them, takes decisions and reshuffles them?
You do not want to put the processes into the Controller due to difficult testability and a mismatch of concern as explained before.
And you do not want to put it into a Model either, since a Model is not a Process but just a business object.
Stated like this, the answer seems to be obvious: a "P" is missing from Rails MVC; Rails is missing an app/processes directory.
(Strangely enough I stumbled over yet another very good article that suggests a more generic and more complex solution. I wonder what happened with its author N. Alex Rupp?)
Tomáš Pospíšek, 2011-01-26