私は、Rails の「スキニー コントローラー」の哲学を理解するようになりました。ビジネス ロジックはコントローラー内にあるべきではなく、基本的にはいくつかのモデル メソッドを呼び出して、何をレンダリング/リダイレクトするかを決定することだけを担当する必要があるというものです。ビジネス ロジックをモデル (または他の場所) にプッシュすると、アクション メソッドがクリーンに保たれます (また、コントローラーの機能テストで ActiveRecord メソッドの長いチェーンをスタブ化することを回避できます)。
私が遭遇したほとんどのケースは次のようなものFooです。それらのそれぞれには、オブジェクトを探しているものに絞り込むメソッドまたはスコープが定義されています (それを と呼びます)。スキニー アクション メソッドは次のようになります。BarBazfilter
def index
@foos = Foo.filter
@bars = Bar.filter
@bazs = Baz.filter
end
ただし、ビューがより階層的なデータ構造を表示する必要がある場合に遭遇しました。たとえば、Foo has_many barsとBar has_many bazs. ビュー (一般的な「ダッシュボード」ページ) で、次のようなものを表示します。ここではfoo、 、bar、およびbazがいくつかの基準でフィルター処理されています (たとえば、レベルごとに 1 つだけ表示したいactive)。
Foo1 - Bar1 (Baz1, Baz2)
Bar2 (Baz3, Baz4)
-----------------------
Foo2 - Bar3 (Baz5, Baz6)
Bar4 (Baz7, Baz8)
ビューに必要なデータを提供するために、私が最初に考えたのは、コントローラーに次のようなクレイジーなものを配置することです。
def index
@data = Foo.filter.each_with_object({}) do |foo, hash|
hash[foo] = foo.bars.filter.each_with_object({}) do |bar, hash2|
hash2[bar] = bar.bazs.filter
end
end
end
それをモデルに落とし込むことはできFooますが、それはそれほど良いことではありません。これは、別の非 ActiveRecord モデルなどに分解する価値のある複雑なデータ構造のようには見えません。各ステップで適用される非常に単純なフィルターを使用して、いくつかfoosとそれらbarsとそれらを取得しているだけです。bazs
このような階層データをコントローラーからビューに渡すためのベスト プラクティスは何ですか?