Designing a reports controller Rails

I am designing a controller for reports. There will be about 10 different reports such as:

• Courses Allocated
• Courses Assigned
• Logins ..etc..

Should I create a controller "reports" that would have urls such as:

/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

There will also be ajax actions that will开发者_JS百科 return data such as get_courses_by_category. (Should this ajax action have it own method, since it has to do with reports, or should this be part of the courses controller)

I am just looking for recommendations on how to design a report system which is mostly just complex sql queries that generate graphs in highcharts (Ajax loaded data) and tabular data.

---

Reporting is annoying, with that in mind you should spend as little time as possible on it. I recommend using searchlogic for make your models easier to query, it'll save you writing all the plumbing from your query string -> sql query.

Another thing that's worth thinking about is that your query roots will most likely be scopes, so if you were to have (for example):

/courses/allocated

That would (maybe) map to Course.allocated.

You could have a report controller, there's certainly nothing wrong with doing that, but I personally like to model my reporting around my existing controllers.

---

I have been thinking about this problem as well and concluded that for a situation where you have reporting associated with multiple models but following similar patterns a reports controller and perhaps generic code in lib makes sense. Reports have needs that are more common to themselves than they are to the models upon which they depend, for example: sort, search, filter, and then charting, exporting to files, permissions, etc.

My rationale is that when designing an application, you should think about it as an API, even if that's not how you are using it. Good APIs are consistent and predictable, and in effect this is what the controllers provide. Simple RESTful CRUD actions (generally speaking) belong in controllers associated with models.

Reporting is different, partly because it tends to cross models, and partly because there are different patterns and are likely to grow over time. For example, we have a report for our business partners that brings together payments, users accounts, and products in a single report; other reports provide a roll-up of metrics across multiple models. Reporting is its own thing.