When should I create a separate controller instead of a custom action in Rails? [duplicate]

Question

This question already has answers here:

OO Design in Rails: Where to put stuff (4 answers)

Closed 9 years ago.

Consider an example where I have an Orders model. Triggering the index action shows all of the orders in the system.

Now I want to have a separate page that displays a chart of all refunded orders and another page that displays all cancelled orders--not only is there now a filter, but a whole new view as well.

What would be a best practice:

1.) Creating new actions in OrdersController for each report (e.g., refund_report and cancelled_report)

2.) Creating new controllers for each report (e.g., RefundReportController, CancellationReportController) with a single show action?

3.) Creating one new controller for all reports (e.g., OrderReportsController) and an action for each report (e.g., refunds, cancellations, etc.

Or is there another paradigm I'm missing altogether?

Answer 1

Go with #1: create actions within OrdersController for each report. This is simple, and it makes sense that a resource (an Order) would have multiple views into it through its associated controller. You're not asking for anything specific to one of these reports yet and it's a good/simple pattern that 1 :get action (and route) corresponds to 1 view.

If, in the future, you find that you're doing a few things specific to a report then consider giving that report its own controller. But that may never happen and no need to abstract early and weigh yourself down now.

Basically, create a new Controller when you want to start thinking of that something as its own entity with its own actions. Don't break something out into a new controller just because the default REST options don't provide a specific member action for what you need.

Answer 2

1.) Creating new actions in OrdersController for each report (e.g., refund_report and cancelled_report)

This is a simple and straight-forward approach. Go with this, if all you are going to do is filter out refunded orders and cancelled orders from Order and display them on their independent views. Also, you don't wish to clutter the index action as well as index view. This is also a better approach if you are not planning on adding any more reports in future and clutter the OrdersController.

2.) Creating new controllers for each report (e.g., RefundReportController, CancellationReportController) with a single show action?

As per the details given in question, the view for Refunded Orders and Cancelled Orders is going to be primarily based on Order model. So, adding new controllers for each report doesn't seem feasible. What are these controllers going to do anyway, just have a single action for refunds or cancellations each? I would not recommend going with this approach.

3.) Creating one new controller for all reports (e.g., OrderReportsController) and an action for each report (e.g., refunds, cancellations, etc.

This is a better approach than both Approach #1 and Approach #2, provided in near future you are planning to add more reports on Order model. With this approach you would be separating the concerns by keeping OrdersController just for the CRUD activities on your Order model and OrderReportsController for all the reports that can be generated on the data retrieved from Order.

I would suggest you to select either Approach #1 or Approach #3 based on your use-case.