今回は業務システムにはつきものの検索画面実装について、以下販売管理システムのサンプルアプリケーションを例に考えてみます。実装したい画面は下図の通りです。商品検索画面システムはproducts(商品)テーブルを持ちます。productモデルは以下の通りです。ActiveRecord::Baseend商品データのサンプルは、下図の通りです。商品サンプルデータシステムの要件は以下の通りです。商品検索画面の検索ロジックをどこに置くのがよいでしょうか。Controller内で複雑なロジックの実装を行ってはいけません。endend上記は俗に言うFatControllerの原因ともなる実装であり、見通しが悪くテストしにくいコードです。検索ロジックをProductモデル内に実装するのはどうでしょうか。悪くない方法ですが、なんでもかんでもProductモデルに詰め込んでしまうと、プロジェクトの規模が大きくなってきた場合に見通しの悪いコードとなってしまいます。FatModel問題を回避するためにも、検索専用のフォームオブジェクトを作成することをお勧めします。contollerに置くロジックはシンプルなものにとどめておきます。endendViewも以下シンプルなものとなります。商品検索画面のロジックを一つのクラスに分離することができました。このように処理を分割することで、見通しのよいコードが書けるようになります。その中にロジックを実装することをお勧めします。複雑な検索を要求されない場合、わざわざ検索専用のフォームオブジェクトを作成するのは面倒です。Ransack(https://github.com/activerecord-hackery/ransack)を利用すれば、手軽に検索画面を実装可能です。Ransackを導入すると、ActiveRecordモデルにsearchとresult関数が追加されます。search関数では、以下のような記法でデータ検索が可能となります。100)記法の詳細については、RansackのWebサイトをご参照下さい。検索画面のController/Viewは、Ransackでは以下のように実装します。%>フォームをPostすると、以下のようなパラメータをコントローラ内で受け取ることができます。"controller"=>"products"}パラメータqの中身を直接Ransackのsearch関数に渡すことで、検索が可能となります。Ransackを利用する場合は、必ずStrongParameterを利用するようにしましょう。以下のような実装はするべきではありません。endendparamの値を直接search関数に渡してはいけません。値は、ユーザが自由に書き換え可能です。そのため、検索画面に存在しない項目もパラメータの渡し方次第で検索可能となってしまいます。思わぬ脆弱性問題に繋がる可能性もあるため、Ransack利用時は必ずStrongParameterを利用するようにしましょう。今回実装したサンプルアプリケーションは、以下ページで取得可能です。