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?
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With