It doesn't take long for the novice Rails developer to come across a
deliberately namespaced controller. (I use the word deliberate because the
class defined in the ever-present
application_controller.rb itself inherits
from a namespaced class. For the sake of brevity, I will omit the word
deliberate going forward). In this post, I will explain the reason behind
namespacing a controller in Rails - i.e., how and why the technique is commonly
In software development, namespacing is a technique by which a class / module / constant or other code is nested within another container. The goal of namespacing in this context is, primarily, to avoid polluting the top-level namespace and avoid naming collisions and, secondarily, to provide context for the nested code.
For example, the constant
PI in the core ruby library is nested within the
Math module. In order to access this constant, you'd have to use the scope
resolution operator (::), like so:
PI is nested within
Math module, I can define another constant at any other scope level and
Math::PI. Furthermore if
PI were ambigious, the fact that
it is nested within the
Math module would serve as a clue to the programmer
what the nested element is / does.
Namespacing a controller in Rails will generate a controller that:
For example, running
rails g controller admin/application will generate a file
application_controller.rb. Because this file 1) lives inside an
directory and 2) defines a class namespaced within
Admin, it does not clash or
application_controller.rb file / class that lives one directory
above the directory tree.
Controllers in Rails are namespaced when you want to perform the same action on multiple resources. Commonly, this action is authorizing a user. By authorizing at the base-level controller and declaring other controllers to inherit from the base, the developer is freed from having to authorize the user in each individual controller.
One can achieve the same effect without namespacing, by creating a base controller that inherits from 'ApplicationController'. For illustrative purposes, let's call this controller 'UserActionsController'. One can define the authorization in 'UserActionsController', and have the controllers that share the same action(s) inherit from 'UserActionsController'.
As far as I can tell, there are only a few downsides to not namespacing a controller. First, you lose the context that is provided by the namespace. Secondly, if I only want certain actions of the same resource protected, I'd have to define the authorization on a per-controller level instead of at the top-level, or I would have to create two separate controllers for the same resource. Because there is no namespacing, the second strategy would require two differently-named controllers for the same resource, a red flag in any Rails project.
In short, namespacing in Rails provides an easy way to create a new base controller in which common actions that need to be performed on a set of controllers can be defined. By avoiding duplicating the same action on a controller level, future changes to those actions become trivial. (It is also a far less error-prone process than defining actions on a controller level).