1

うまくいけば、レールのベストプラクティスに関する簡単な質問です。

これは非常に単純にしましょう。ID、説明、およびステータスを持つタスク モデルがあるとします。

私のコントローラーには、すべてのタスクを返すインデックスアクションがあります

def index
  @tasks = Task.all
end

私の質問は、私の見解では、ステータスに応じてタスクを個別の HTML テーブルに表示したいとします。

ベストプラクティスは何ですか?

a) index アクションでデータベースを複数回クエリします。

def index
  @draft_tasks = Task.where(status: "Draft")
  @approved_tasks = Task.where(status: "Approved")
  @closed_tasks = Task.where(status: "Closed")
end

b) データベースに 1 回クエリを実行し、コントローラー アクションでフィルター処理する

def index
  tasks = Task.all
  @draft_tasks = tasks.#somethinghere
  @approved_tasks = tasks.#somethinghere
  @closed_tasks = tasks.#somethinghere
end

c) ビューでフィルター処理する

<% @tasks.each do |k, v| %>
  <% some if statement searching for the status I want %>
    # Some code to output the table
  <%end%>
<%end%>

また

d) 他に何かありますか?

4

4 に答える 4

3

ここで一般的に受け入れられているベスト プラクティスは、コントローラー メソッドを薄く保ち、ロジックをビューから除外することです。それを念頭に置いて、これを行う1つの可能な方法は次のとおりです。

# model
class Task
  scope :drafts, where(:status => "Draft")
  scope :approved, where(:status => "Approved")
  scope :closed, where(:status => "Closed")
end

# controller
def index
  @draft_tasks = Task.drafts
  @approved_tasks = Task.approved
  @closed_tasks = Task.closed
end

これにより、データベースに対して 3 つのクエリが作成され、将来的にパフォーマンスの問題になる可能性がありますが、それが発生した場合は、モデル レベルで最適化できます (たとえば、クラス メソッドdrafts、approved、およびclosed最初に呼び出されるメソッドがすべてをプリフェッチする場所を定義することにより)。 . ただし、あまりエレガントではないため、時期尚早に最適化しないでください。

于 2012-07-04T04:48:11.610 に答える
1

タスクの数が制限されている単純なケースでは、タスクを取得するために1つのクエリのみを実行し、次のようにそれらを分離します。

tasks = Task.all
@draft_tasks    = tasks.select { |x| x.status == 'Draft' } 
@approved_tasks = tasks.select { |x| x.status == 'Approved' }
@closed_tasks   = tasks.select { |x| x.status == 'Closed' }

さらに、要件の曲げやすさに応じて、状態が何であるか（背景色やアイコンなど）を明確に視覚的に示すマーカーを使用して、単一のテーブルにレンダリングすることもできます。そうすれば、事前にタスクを分離する理由すらありません（ただし、これによりUIが完全に壊れることは想像できます）。

タスクの数が増えると、上記のいずれも有効になりません。ページネーションを適用する必要があり、3つの異なるテーブル（状態ごとに1つ）を表示する必要があります。

その場合、@Benが回答した3つの個別のクエリを使用する必要があります。

UIに関しては、3つの異なるデータセットを一度にページ分割する方法がわかりません。したがって、代わりに、すべての状態を示す単一のテーブルを使用し、ステータスでフィルタリングするオプションを提供します。その場合、少なくともユーザーにとって、ページネーションが何を意味するかは明らかです。

ちょうど私の2セント、これが役立つことを願っています。

于 2012-07-04T23:22:47.813 に答える
1

これは、私の意見ではベストプラクティスのない負荷の高い質問です。あなたが述べたケースを考えると（それぞれの表を表示してくださいstatus）、私は次の思考プロセスを使用します：

  1. 1 つのモデル タイプだけを扱っている場合は、通常はケース A を避けます。可能な限り、データベース クエリの数を制限するようにしています
  2. statusケース B は、ビューがタスクに応じて異なるマークアップを表示する必要がある場合に使用するものです。

  3. 各 のマークアップが同じ場合、通常はケース C の傾向がありますstatus。これにはgroup_by関数を使用できます。

ページ上の情報量が増えて複雑になってきたら、コントローラーから別のオブジェクトにロジックを抽出することを検討できます (このオブジェクトの一般的な用語はpresenterやdecoratorです)。これにより、プレゼンテーション ロジックをコントローラーから分離し、コントローラーを「薄く」保つことで、一部のプレゼンテーション ロジックのテストが容易になります。しかし、あなたが与えたケースでは、オプションbまたはcに固執します.

于 2012-07-04T04:57:38.790 に答える
0

オプションa）データベースがクエリをキャッシュできるという理由だけでより良いように思われるので、より高速になるはずです。

于 2012-07-04T04:43:28.783 に答える