报表控制器Rails的设计

Question

我正在为报告设计一个控制器。将会有大约10份不同的报告，例如：

• 分配的课程
• 分配课程
• 登录..etc..。

是否应该创建具有urls的控制器"reports“，如：

/reports/courses_allocated?course=abc&start_date=2001-01-01&end_date=2011-01-01 /reports/courses_assigned?course=abc&start_date=2001-01-01&end_date=2011-01-01

还有一些ajax操作将返回数据，如get_courses_by_category。(这个ajax操作是否有它自己的方法，因为它与报告有关，还是应该是课程控制器的一部分)

我只是在寻找关于如何设计一个报表系统的建议，这个系统主要是复杂的sql查询，这些查询生成高图表(Ajax加载的数据)和表格数据中的图形。

Answer 1

报告是烦人的，考虑到这一点，你应该尽可能少地花时间在上面。我建议使用搜索逻辑使您的模型更易于查询，这样可以节省您从query string -> sql query编写所有管道的费用。

另一件值得考虑的事情是，您的查询根很可能是作用域，所以如果您有(例如)：

/courses/allocated

这将(可能)映射到Course.allocated。

您可以有一个报表控制器，这样做当然没有什么问题，但我个人喜欢以现有控制器为我的报告建模。

Answer 2

我也一直在考虑这个问题，并得出结论:对于与多个模型相关联的报告，但遵循类似的模式，lib中的报表控制器和通用代码是有意义的。报表的需求比它们所依赖的模型更常见，例如:排序、搜索、筛选、然后绘图、导出到文件、权限等。

我的理由是，在设计应用程序时，您应该将其视为API，即使这不是您使用的方式。好的API是一致的和可预测的，实际上这就是控制器所提供的。简单的RESTful CRUD操作(通常来说)属于与模型相关的控制器。

报告是不同的，部分是因为它倾向于跨模型，部分是因为有不同的模式，并且可能随着时间的推移而增长。例如，我们为业务伙伴提供了一份报告，该报告将支付、用户帐户和产品合并到一个报表中；其他报告提供了跨多个模型的度量汇总。报道本身就是一回事。