Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why does Rails create a controller for every request?

From my previous question I understood that Rails creates a controller instance for every request.

My question is, because this subject is related to the design of the project I'm working on:

Why does Rails creates a new instance of

class SomeController < ApplicationController; end

to process every incoming request? Why not just create singleton object and forward requests to this one? This seems more efficient as we won't waste resources on allocating and cleaning objects for request?

like image 510
megas Avatar asked Jan 05 '13 14:01

megas


People also ask

What does controller do in Rails?

The Rails controller is the logical center of your application. It coordinates the interaction between the user, the views, and the model. The controller is also a home to a number of important ancillary services. It is responsible for routing external requests to internal actions.

What is Before_filter in Ruby on Rails?

Before Filters ADVERTISEMENT. ADVERTISEMENT. Rails before filters are executed before the code in action controller is executed. The before filters are defined at the top of a controller class that calls them. To set it up, you need to call before_filter method.

What are controller callbacks in rails?

Rails provides before and after actions in controllers as an easy way to call methods before or after executing controller actions as response to route requests.

How do params work in Rails?

Specifically, params refers to the parameters being passed to the controller via a GET or POST request. then the controller would pass in {:name => “avi”} to the show method, which would set the @person instance variable to the person in the database with the name “avi”.


1 Answers

The overhead of instantiating a new controller instance is insignificant, and it means there is no accidentally shared state between two completely unrelated requests. Any "savings" in processor time would be more than offset by the potential to produce devastating bugs.

Remember that controllers are for storing request-specific state. Reusing controllers would require you to reset every @variable you'd ever set, at the start of every action. Otherwise, something like @is_admin = true could wind-up being set and never cleared. The less contrived bugs you'd actually be introducing would be much more subtle and draining on developer time.

You're seeing optimizations where there are none. Something must maintain state and reset it between requests, or you have this nightmare of accidentally shared state. If you persist controller instances between requests, you're simply pushing the job of maintaining/resetting state down to some lower level, where the answer will likely still be to instantiate a fresh instance of some state-managing class for each request. Computers are very good at allocating and freeing resources, so never worry about that until you actually know it's a bottleneck. In this case, instantiating a new controller for each request is easily the correct choice.

In the case of Rails, being able to use @variable = value is a major win from a code-clarity and usability stand-point, and this more or less necessitates discarding each instance of a controller when the request completes.

like image 80
meagar Avatar answered Oct 11 '22 10:10

meagar