Greg W. wrote:
On Jun 6, 2008, at 11:36 AM, Carsten G. wrote:
- Calculated fields based on selected data
Controller
Everything that has to do with with HTTP requests and responses goes
into the Controller.
The controller is the only place, where you should handle “params”,
“session”, “cookie”, etc.
If you find yourself with a controller method, that spans more than 20
lines, then some of it probably belongs in the View or Model.
pepa007: ignore my discussion below – from what I can tell Carsten’s
rules are fairly generic in the Rails community, I’m raising more
“advanced” ideas, and likely ones the Rails view of the world doesn’t
agree with, or I’m wrong 
Ahh… I like a good discussion. Well as long as your arguments are
good, your ideas don’t need to match those of everyone else.
One of my struggles with Rails is this notion of skinny controllers
and fat models. I don’t buy it. At least, not as a “rule” – as a
more than likely guideline, I’ll agree it’s what you consider first
to see if it fits.
I made an error in my description of the controller. I wrote:
The controller is the only place, where you should handle “params”,
“session”, “cookie”, etc.
But I did not mean, that this nessecarily is the ONLY things, that the
controller should handle.
The 20-lines “rule” should just be a gauge when you revise your code.
OOP idioms say that each method should be as simple as possible and not
fullfil more than one task. This also goes for methods in a controller.
Each method (action) should only handle one task - if you create too
many dependencies in a method, something is wrong with your design.
I don’t know yet, if I hold with the “skinny controller” idea, neither
with “each controller should just contain CRUD operations”. It might
impose too much constraint on your design and force you to invent
ressources that aren’t really there.
MVC, IMO, does not dictate concepts like skinny controllers and fat
models and thus some of the rules stated above. I can see where this
comes from with a Rails controller pretty much intended specifically
for handling the final step of request-specific routing, but the
adoption of the notion that all other logic belongs in the model
doesn’t make sense to me. The domain-logic layer feels rather ignored
to me in Rails. Ignored, or maybe just oversimplified.
I agree with you. The basic Rails introductions fail to discuss where to
put methods/code that interact with more than one datastructure at once.
Models are described as simply being classes on top of a database table.
So 3 tables => 3 model classes. With this scheme, people are tempted to
put domain-specific code into the controller, when they need to operate
on more than one table at a time.
I have models (stripped down data structures) which I reuse with
different business logic. Sometimes, even different validation rules,
so not entirely fond of having validations attached to models either–
I prefer delegation for that role. Same for the business rules.
Separation of data & rules dictates that business logic lives outside
of the model.
I don’t think, that business logic should live outside the model. A
model IMHO is responsible for validating data that it accepts into its
data-layer.
The problem occurs when validation in one model is depending on another
model.
So, while for the majority of dead-simple web sites and simple web
applications that are straight forward hand-to-mouth request to data
handling, then I suppose these rules pretty much apply. But the idea
that once a controller method starts to get to be 20 lines something
probably belongs in the model–I don’t buy that at all. The code may
belong somewhere else, but to assume that it is always in the model
(as it would rarely likely belong in the view), I think is misleading
to sell it as an OOP rule of thumb.
Again I agree. The code need not nessecarily be put into the model, but
most of the time it implies, that something is made unnessecarily
complex, and could be refactored out into “service” methods/classes.
Maybe I’m
just over reacting to advice that’s good to give 99% of beginners,
My reply was exactly that - a beginners guide.
but I find myself at odds with Rails design edicts from time to time,
That is why they call it “oppionated software”. 
I have also had my disagreements with Rails. Coming from the free world
of C/C++, PHP and Perl, I am not used to the straight-jacket approach,
that Rails forces. But I’ve found myself programming faster in Rails
than in any other of the aforementioned languages - even from my first
Rails project - so I have reluctantly accepted that it is “The Rails Way
or the Highway”. A price I now gladly pay for the power I get.
