我正在为报告设计一个控制器。将有大约10种不同的报告，例如：
我是否应该创建一个控制器“报告”，其中包含以下网址：
？/报告/ courses_allocated当然= ABC＆安培;起始日期= 2001-01-01＆安培; END_DATE = 2011-01-01 ？/报告/ courses_assigned当然= ABC＆安培;起始日期= 2001-01-01＆安培; END_DATE = 2011-01-01
还会有ajax操作返回get_courses_by_category等数据。 （这个ajax动作是否有自己的方法，因为它与报告有关，或者这应该是课程控制器的一部分）
我只是在寻找有关如何设计报表系统的建议，这些报表系统主要是复杂的SQL查询，它们在highcharts（Ajax加载数据）和表格数据中生成图形。
答案 0 :(得分：3)
报告令人讨厌，考虑到这一点，您应该花费尽可能少的时间。我建议使用searchlogic让您的模型更容易查询，这样可以节省您从query string -> sql query编写所有管道的费用。
值得考虑的另一件事是你的查询根很可能是范围，所以如果你有（例如）：
/courses/allocated
那会（也许）映射到Course.allocated。
你可以拥有一个报告控制器，这样做肯定没有错，但我个人喜欢围绕我现有的控制器建模我的报告。
答案 1 :(得分：3)
我一直在考虑这个问题，并得出结论，对于你有报告与多个模型相关但遵循类似模式的情况，报告控制器和lib中的通用代码是有意义的。报告的需求比它们所依赖的模型更为常见，例如：排序，搜索，过滤，然后绘制图表，导出到文件，权限等。
我的理由是，在设计应用程序时，您应该将其视为API，即使这不是您使用它的方式。良好的API是一致且可预测的，实际上这是控制器提供的。简单的RESTful CRUD操作（一般来说）属于与模型关联的控制器。
报告是不同的，部分原因是它倾向于跨越模型，部分原因是存在不同的模式并且可能随着时间的推移而增长。例如，我们为业务合作伙伴提供了一份报告，该报告将付款，用户帐户和产品汇集在一个报告中;其他报告提供了跨多个模型的指标汇总。报告是它自己的事情。