私はプロジェクトに参加しています。これは、exterarily Presenterパターンを使用しています。コントローラテストのPresenterパターンのメリット
プレゼンタークラスのすべてのメソッドは次のように、些細ているので、私は、それのメリットが表示されていない。
class Checkout::NewPresenter
def initialize(customer, order)
@customer, @order = customer, order
end
def customer
@customer
end
def order
@order
end
end
Guysは、このパターンは、コントローラのテストがより簡単になりますことを、私に話しています。我々はコントローラのロジックから抽象化されており、特定の戻り値でプレゼンターオブジェクトをテストするだけでよい。
しかし、この効果は、プレゼンターレイヤーなしでコントローラのインスタンス変数を調べることで実現できます。
私はSimplifying your Ruby on Rails code: Presenter pattern, cells plugin準備ができてきたし、最初のケースでのみ同意：
あなたは広範囲にあなたのモデルを使用して、あなたのビューでいくつかのロジックを、持っています。そのような論理を持つ他のビューには場所がありません。古典的な推奨事項は、このコードをモデルに移動することですが、短時間のあいだ、モデルは愚かな一回限りのヘルパーメソッドで膨らみます。解決策：パターンプレゼンター。
私は2番目のケースを理解していません。
コンストラクタには、データベースまたは別のストレージからビューの値を取得するためのコードが多数含まれています。あなたはfragment_existをたくさん持っていますか？対応するフラグメントがすでにキャッシュに入っているときに、データが確実にロードされるようにするための呼び出し。サイズのため、特定のアクションをテストすることは本当に難しいです。解決策：パターンプレゼンター。
また、コントローラのテストでは、インスタンス変数のみを調べています。ここでの意味
主な質問は、コントローラーのテストにPresenterパターンがどのようなメリットがあるかです。