Help Grokking Controllers (It's not as gross as it sounds.)

August 25, 2007 9:18 AM

Looking for guidelines, principles, etc. for grokking the decision process for splitting up a Ruby on Rails application into controllers.

So, I'm learning Ruby on Rails. I get the model and view part of MVC quite well. But the controller aspect still eludes me some. When I watch various screencasts and read the Agile book, the decisions make sense to me, but when I start to create an application, the decisions about controllers aren't as readily apparent to me.

So, how do you think about controllers when you are developing an application in Ruby on Rails? What sort of guidelines or cues do you keep in mind that make you know you should create a new controller as opposed to a new action in an existing controller?

I hope that makes sense. My ability to express the question cogently clearly corresponds to and confirms my uncertainty.

posted by jxpx777 to computers & internet (4 comments total)

At the very least they need to provide a data transfer layer between the models and the views. Beyond that, controllers can do management of transformations between models, and also they can wire up permissions and stuff.

Models should hold business logic, like "find_all_open_orders", rather than just calling "find_orders" and then looping over it to find open ones.
posted by cschneid at 10:52 AM on August 25, 2007

As for when to create a new controller versus just another action, what I do is to separate out the application based on large scale "job" the user is doing. So there is an admin controller, a profile controller, and so on.
posted by cschneid at 10:56 AM on August 25, 2007

A lot of people seem to put lots of logic into their controllers. That's probably not a good idea. The controller should be responsible for receiving a request. The models should manage the logic side of things, as they're responsible for data storage and consistency.

As cschneid said, controllers are good for system-level stuff like access management (see before_filter) and for telling the view which layout or template to use. Usually you would use the controller to figure out which models need to be shown in a given view.

If you dig the REST way of doing things, your controllers become extremely cookie-cutter. In fact, REST makes the controllers basically windows into the models, so if you're able to envision your data layer, you may want to start there and then add use-case controllers later.

You say you've read the Agile book; if you have a look at the controllers from the Depot application (from page 655 in my PDF), you'll find that they aren't doing much: finding data, instancing a model and sending back the result of a save attempt, and managing authentication. The only controller a 'normal' user would ever see is the StoreController.

The way I'm doing things: authentication lives in one controller (authorization lives in application.rb usually), shopping lives in another controller, and the account management (including checkout) lives in another controller.
posted by lowlife at 12:06 PM on August 25, 2007

I usually have a controller for each of the logical site objects a user (or another process) can interact with. Events, Posts, News, etc...

Perhaps it would help if you could describe one of your applications that you're having trouble conceptualizing.
posted by Caviar at 10:34 AM on August 26, 2007