我正在設計一個報告控制器。將有大約10不同的報告，如：設計一個報告控制器Rails
我應該創建一個控制器「報告」，將有例如：
/reports/courses_allocated？course = abc & start_date = 2001-01-01 & end_date = 2011-01-01 /報告/ courses_assigned？當然= ABC &起始日期= 2001-01-01 & END_DATE = 2011-01-01
也將有將返回數據如get_courses_by_category阿賈克斯行動。 （這個ajax動作應該有自己的方法，因爲它與報告有關，或者應該成爲課程控制器的一部分）
我只是在尋找關於如何設計報告系統的建議，以高圖（Ajax加載數據）和表格數據生成圖表的sql查詢。
報告很煩人，考慮到這一點，你應該花盡可能少的時間在它上面。我建議使用searchlogic，以便讓您的模型更易於查詢，這將節省您編寫query string -> sql query的所有管道。
這是值得思考的另一件事是您的查詢的根將最有可能範圍，所以如果你有（例如）：
/courses/allocated
那倒（也許）地圖Course.allocated。
你可能有一個報告控制器，這樣做肯定沒有錯，但我個人喜歡圍繞我現有的控制器建模我的報告。
我一直在考慮這個問題，並得出結論，對於一個情況，你有報告與多個模型相關，但遵循類似的模式，報告控制器和可能在lib通用代碼是有道理的。報告具有比他們所依賴的模型更普遍的需求，例如：排序，搜索，過濾，然後製圖，導出到文件，權限等。
我的理由是，當設計一個應用程序，你應該把它看作是一個API，即使這不是你如何使用它。好的API是一致的和可預測的，實際上這是控制器提供的。簡單的RESTful CRUD操作（一般來說）屬於與模型相關的控制器。
報告是不同的，部分原因是它傾向於跨越模型，部分原因是由於存在不同的模式並且可能隨時間增長。例如，我們爲我們的業務合作伙伴提供了一份報告，該報告將付款，用戶帳戶和產品彙總到單個報告中;其他報告提供了跨多個模型的指標彙總。報告是它自己的事情。
感謝您的回答。它似乎searchlogic不軌3兼容，（我忘了提及我正在使用rails 3）。你還有其他建議嗎？ – 2011-03-15 17:43:54
我還沒有嘗試過，但也許看看http://metautonomo.us/2010/03/07/metasearch-object-based-searching-for-rails-3/ – jonnii 2011-03-15 17:46:26