How to Split Controller Descriptions in Rails

Creating a BaseController and moving it there is probably not a good idea. Instead of Hoge, the base gets bigger and the punchline flickers.In general, inheritance should only be done when the Hoge ISA Base relationship is established.

The principle is to divide responsibilities appropriately. (Quoted from Try deploying services and forms in Rails)

As you can see in your other Question, consider moving what you can to a model or deploying the services and forms listed in the above entry.

Another possible approach is to "handle multiple requests within a single controller" as a factor in the controller's enlargement.For example, if you apply a RESTful design, it is common to define operations (CRUDs) for a resource within a single controller.In other words, there are at least four methods for receiving requests for CRUD.The larger the processing in each method, the larger the controller.

If it is in that state, I think it is possible to rewrite config/routes.rb and create a separate controller for each CRUD.This may reduce the content of each controller by a quarter in simple calculations.

Otherwise, if the processing of one request is bloated, you will need to take the measures described in the above answer.

I don't think this method is generally good.It depends on the situation.

Here are two ways I've done it before:

• Share common parts of controllers into base classes

• Codes operating multiple models on controllers are independent, aggregated, and called by the controller to reduce the controller code

Controllers share commonality in base class across multiple controllers

Code that operates multiple models on the controller independently as a data-free model and aggregates them into a form called by the controller, reducing the code on the controller

I think the former is a valid approach if there are multiple models that operate and they have parent-child relationships, and similar operations for both parents and children, or for multiple children.

The latter is useful for controllers that perform many operations across multiple models.

On the other hand, if the model has a certain size and there are many unique operations, I think it is inevitable that more code will be included in the controller part.

Also, one thing to be aware of is that the controller acts as an intermediate (model model of the app) and an external (user or external system), so there are restrictions and the implementation is bound by anyhow.This kind of discussion makes people think that the design of the model is bad, but the controller is not limited to UI, but also serves as an interface between the internal model and the external model, so I think there are times when I can't say anything.For example, no matter how simple the internal model is, it has to produce some complex output.

Therefore, considering the ease of viewing and the degree of code sharing, we have no choice but to choose from the above methods.

I think it would be a good idea to use Concerns well.However, the location of the cord is quite far away, so it's hard to see.

I also made a BaseController for Rails 3.2 and wrote a common process, but in the end it got bloated and my outlook got worse.

Therefore, we have broken it down into parts called Concerns which are also used in models and others, so that we can add them if necessary.

For example, concerns was injected with exception handling that required JSON output as shown below.

module ExceptionHandler
  extend ActiveSupport::Concern

  included do
    rescue_from Errors::BadRequest, with::bad_request
  end

  protected
  def bad_request(exception)
    render_exception status: __method__, debug_message: [exception.message, exception.backtrace].join("\n")
  end

  defrender_exception(args)
    status=args[:status].to_sym

    error_message={
      status_code —Rack::Utils.status_code(status),
      status: status.to_s.humanize,
      message:args[:message]}

    response_to do | format |
      format.json {render json:error_message, status:status}
    end
  end
end

Basically, we don't use Scaffold or Generator when we create our own structure, but if you're generating with the rails generate controller MyController command, you can skip the product with a few options.

 --skip-template-engine(--no-template-engine)# Skip View generation