Put code in model or controller. Any general rules of thumb?
Per Velschow
perhaps a strange path to learning Rails. I started getting experience
with Ruby - lovely language indeed! Then I ventured into ActiveRecord.
Slick and easy to understand framework.
Now, I am starting on the controllers. But that gives me some doubts. I
am constantly wondering if I have bloated my models with too much code.
So I would like to ask if there is perhaps a write-up somewhere about
what to consider when deciding between putting code in the model or in
the controller?
When I get to learning about the views, I will probably wonder about
the same issue. I understand that the rule of thumb here is basically
to put as little code in the view as possible. So again that leads back
to the question of putting the code to support the views in the model
or the controller.
I know these are pretty general questions. And I am certainly not
looking for a "fact book". Just some insight into how other people tend
to make their decisions about where to put the code. :)
Andrew Skegg
This helped me :
http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model
--
Posted via http://www.ruby-forum.com/.
Rajkumar S
> I am a Rails newbie (but far from a programming newbie).
So am I so take the rest of the mail with a pinch of salt. :)
> So again that leads back
> to the question of putting the code to support the views in the model
> or the controller.
when I started my first RoR app, views were pretty fat, after my first
iteration I moved most of the code to controller, now in my second
iteration I am moving things to model as much as possible. My rule of
thump is that you should not be using Model.find() in your controller.
Write helper methods in your model to get the data in the form you
want. That will lead to more consistency and leaner controller. But
take care not to take this to insane levels :)
Also checkout this blog post for more details from some one with more
clue than me. http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model
raj
Sheldon Hearn
It took me a long time to settle on a simple decision process that
works for me, especially in the J2EE environment where it's not as easy
to change your mind.
I default to trying to push code down into the model. However, I ask
myself these two questions:
1) Does this code describe anything other than behavior of this model?
2) Does this code know about CGI or HTML?
If the answer to either of those questions is yes, I look more
seriously at putting the code in the controller or an helper. If the
answer is "yes and no", I'm probably trying to do too much at once, and
need to break it up across the layers.
In summary, favor the model, but not at the cost of layering
violations.
The attitude that this comes from is that your domain model (your
collection of "models") is the system. The controller is only there to
mediate a view into it. This attitude works well for the kinds of
applications Rails is suited to.
Here are two more considerations:
1) Code that you put in the model is easy to use from the Rails console
and runner. Code that's in the controller is more of a pain in the arse
to get to.
2) Model instances can call each others' methods, but they can't call
methods on controllers without jumping through hoops.
Ciao,
Sheldon.
Ilan Berci
> You're asking the right questions. :-)
>
> It took me a long time to settle on a simple decision process that
> works for me, especially in the J2EE environment where it's not as easy
> to change your mind.
Sheldon,
Your entire response was great! I really enjoyed reading it and I don't
believe anyone could have said it any better.. Thankfully I have no
scruples, so I will simply steal yours and next time I get this
question, I will be sure to impress! :)
ilan