Controller Hierarchy

In most of the rails I have met, the structure of the controllers has no organization and the project grows as it should. In large projects, this leads to the fact that controllers become huge (with dozens of actions), and conditional filters are stretched to full screen. To understand this code is not very easy.

Having worked with a large number of rails projects, I had an approach to organizing the hierarchy of controllers, which allowed us to unify their structure and simplify the code.


')

Upper level

First of all, it is convenient to locate the main names of the project, such as web, mobile, api, feeds and others, on the top level. In this case, the admin module will be in the web.



Inside api, you can also select submodules divided by version, for example, v1, v2. Or make folders on the top level api1, api2, etc.
link: freelancing-gods.com/posts/versioning_your_ap_is

I use this structure even in the simplest cases. Practice shows that any of these components can easily be added when no one planned it.

For each module, a Namespace :: ApplicationController is created in order not to mix logic suitable for specific namespaces.



But in the routing there will be small differences for different modules. Web is set as scope. As a result, we will get helpers without unnecessary prefixes, but for the rest, we use the namespace.

Investment resources

I'll start right away with an example: user profile on the site. It can be accessed by this url / users /: id and its UsersController controller. The list of user's posts is available by / users /: id / posts. Accordingly, we have PostsController with an index within which we get posts for the user. Then we have the task to display all the posts in one list. We use the same posts controller and add the index_all method there. In this case, the user is no longer needed. In the end, adding a variety of views, there will be a part of the methods that derive these posts (and process them) for the user, and some without him. Then filters will appear, for example, before_filter: load_user,: only => [: index ...], and so on until there are no people left who can understand what is happening here.

The same will happen again to display comments, likes and more. At the same time, the output of posts can be not only by user, but also by category and many other links in which posts will be nested resources.

In this case, it would also be wise to create modules for the appropriate resources.



And for each namespace there will be its own ApplicationController containing common module methods.



For all controllers located in this module, current_section without filters will be available.

Profit:

Controllers are getting smaller and simpler.
Looking at the structure of the controllers, we can already say a lot about how the project is organized and what can be expected in a particular controller.
Many conditional filters go away.
Simplified testing;
Unified organizational approach;

Also, for convenience and uniformity, the namespace input controllers are called welcome. And connect to routs via root: to => 'welcome # index' inside the corresponding scope.
Real example:

Consider how to organize controllers for a real example. Say it took to do integration with facebook.

When approaching the forehead, some kind of FacebookController controller would be made, in which all methods for working with Facebook would be placed. As a result, we would get a part of the methods, which should work only from the user account, and some only for those who are not authorized, etc.

Split approach:

resource :facebook, :only => [:new, :create] 

In this case, nothing is known about the user, but when the integration changes (for example, autoshare setting) or deletion, we work with a specific user. This can be implemented, for example, as follows:

 # app/controllers/web/account/facebook_controller.rb resource :account do scope :module => :account do resource :facebook, :only => [:edit, :update, :destroy] end end 

And if you need to give the opportunity to integrate an already authorized user? Then in the last example add: new,: create.

As a result, instead of one controller, we got two (but maybe more if the task requires it), but all the methods are grouped by use case.