When to create a new controller in rails

Question

UPDATE: I highly recommend reading How DHH Organizes His Rails Controllers which pretty much explains it much better than my original answer.

---

I think the question would be more suitable if you'd put it another way:

Why do we need model (AR in this case) for every controller?

And the answer of course is, you don't. When you are thinking about controllers it's best not to think about data, but take a slight step back, and think about resources. If you search for REST in internet, you will find a lot of articles and most of them will include various explanations of terms resource and representation. To make this story short, let's just oversimplify and say that resource is everything that's worth mentioning. Articles is a (collection) resource. Store is a (singular, member) resource.

Take signing in users for example. You probably already have UsersController which (by default) will allow you adding new users (create resource), deleting them (remove resource), displaying single user and also all users. If you just think in terms of data and controllers, you probably would start creating additional actions like login_user in UserController, which is a smell. If you think about resources, and that is "everything that's worth mentioning about or creating URI for it", you might think that you need another resource, and that is: sessions. Think about this way: when user signs in, they actually create a session resource. And with sign out, you delete, remove the resource. It is much better explained in the Rails tutorial book which I recommend: http://ruby.railstutorial.org/chapters/sign-in-sign-out#sec:sessions

To recap, this may help you in figuring out when you need new controller:

• When you think about putting non RESTful actions in controller like log_in, calculate_date, ect.
• When there is something that you can name and that is "interesting" enough to be a separate resource.
• Also, when you are developing in "outside in" style, such answers come more naturally: http://rubylearning.com/blog/2010/10/05/outside-in-development/

Overall, learning about REST and its philosophy will help a lot.

Obviously, there's no hard-and-fast rule; but I think it's helpful to think in terms of what the three different parts of MVC represent (or "do"):

• Models represent the data and data-logic backend
• Controllers let the user interact with the models
• Views are what the user sees when the user interacts via a Controller

So different controllers would be used for when you want to do different (categories of) things.

For instance, in the AWD book, the Depot application works (broadly) by manipulating and storing Products - so it has a Product model.

There are two distinct ways of interacting; as the owner of the Depot (adding products, adjusting prices and stock...) or as a customer (adding products to your cart, checking out...). So it has an Admin controller for the former, and a Store controller for the latter.

Another reason, and one which will often tie into the first, is if your controllers need different wrapping. For instance, you need to authenticate the user before doing any Adminy stuff, but you don't for Customer-based things. So you can separate the actions into two controllers, and put a before_filter on the Admin one to handle authentication.

I am also new to RoR and I am doing a tutorial from Michael Hartl. I found in my research and in talking with more seasoned Rubyist that when you need the help of your Model (database) you should create a Controller. For example, if you are creating a session and the method that you are creating is going to need interfacing with the Model (database) by using, storing, updating, adding (a.k.a. RESTful behavior) then you will need a controller.

Why? As stated before: the MVC frame work requires that Controllers be the only element that can interact with the Models (kinda like a bouncer at the V.I.P.section of a night club filled with hot women! The geeks are represented by "the view" LOL!!)!!