CODEWITHSUNDEEP
ruby-on-railsrubymodelcontrollerfunction
overtone
overtone

Reputation: 1093

Deciding whether def should belong to controller or model (Ruby)

So its a fairly noobish question. Im still coding a web spider and have lots of questions but the first one I want to ask is how do you decided whether a method should belong to a controller or a model.

I don't want to bring my application into this as there are many specific "does this code belong in controller or model" questions whereas I'm hoping this question will just serve as a general guideline.

Upvotes: 0

Views: 150

Answers (2)

d11wtq
d11wtq

Reputation: 35298

I've worked in many environments, in many languages, ranging from entirely procedural, to object-oriented but not MVC, to MVC with fat controllers and MVC with skinny controllers. I can only speak of my own opinions, but these are things I've learned over the years and opinions I've gained through experience and having to deal with the maintenance consequences of some of the early code I wrote (we all have a past!).

I also know that many people will disagree with what I write here, as that is the nature of how we work ;)

  1. Fat controllers are generally bad. It probably indicates that you have model logic in your controllers and where models are used in more than one controller, there's a good chance some of that logic is being needlessly duplicated.
  2. Controllers should give as little information as needed to their views, and the views should be able to "pull in" what else they need, by asking one or two core models for it (e.g. don't worry about passing in a model and its associations as separate variables. Pass in the model and let the view fetch the associations if needed. I've worked on systems (in fact, I'd say, unfortunately, most systems) that pass 10's, 20's, 30's of variables into a view, when many of those could simply have to been loaded on-demand by the view itself. I think Rails generally does a good job of encouraging a model-pull methodology, but I'm talking about MVC (on the web) as a broader concept.
  3. Views can use complex logic. Some projects I've worked on thought that because something in a view was more than a simple "for each" loop, it therefore needed to be stuffed into the controller. That is wrong. Your controller is then performing view logic. The view is code... let's not hide that fact.
  4. Relating to point (3), don't confuse "template" with "view" as a whole. The template is just part of your view.

I'm drifting off-topic here, but in short, most of your logic should probably finish up in your models. Your models, well, model your application in terms of data and how that data changes. It's therefore natural that this is where a lot of logic is placed. Your controllers only serve to transport information between the models and your end user (which just so happens, to be via the view).

Quite a long-winded way to say "I agree with John", eh? ;)

Upvotes: 2

John Beynon
John Beynon

Reputation: 37507

I always go with Skinny Controller, Fat Models as far as I can - so the answer to your question is usually the model.

Upvotes: 5

Related Questions