CODEWITHSUNDEEP
ruby-on-railsruby-on-rails-3ruby-on-rails-3.1
user469809
user469809

Reputation:

When to create a new controller in rails

I'm wondering when you know that you need to create a controller in a rails application.

For example, I'm going through the tutorial in Agile Web Development with Rails and the application creates several models, all with seperate views and contollers. However, we also then create a Store controller, but no model associated with it. Why do we need a controller with no model? Couldn't the controllers for the models handle all required operations?

Is this common? If so, how do you determine when something warrants a controller?

Thanks!

These answers help, thank you.

My concern is that when I develop something on my own, I will begin to create useless controllers, or on the flip side, not create necessary controllers. But, I suppose I need to stop thinking of controllers and models as a 1-1 relationship, correct? If I'm understanding correctly, there could be many controllers accessing a model and many models being used in one controller?

Upvotes: 31

Views: 8981

Answers (4)

Ernest
Ernest

Reputation: 8829

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.

Upvotes: 36

Serious
Serious

Reputation: 153

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!!)!!

Upvotes: 1

Chowlett
Chowlett

Reputation: 46675

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.

Upvotes: 8

davidb
davidb

Reputation: 8954

A controller can be used to create pages with no boundary to a model. An example for that might be an legal notice or sth. like that. Static stuff,...

A Controller controlls data. In most cases these data comes from the Model but this isnt necassary wheater its the most common combination.

Upvotes: 0

Related Questions