Ruby on Rails 開発 (一般的には MVC) で、ロジックをどこに配置するかについて、どのようなクイック ルールに従う必要がありますか。
Don't put that thereではなくDo put this hereで肯定的に答えてください。
Ruby on Rails 開発 (一般的には MVC) で、ロジックをどこに配置するかについて、どのようなクイック ルールに従う必要がありますか。
Don't put that thereではなくDo put this hereで肯定的に答えてください。
MVC
Controller : ユーザーが何を望んでいるのか、ユーザーに何を提供するかを決定すること、ユーザーがログインしているかどうか、特定のデータを表示する必要があるかどうかなどに関係するコードをここに配置します。最終的に、コントローラーはリクエストを確認します。表示するデータ (モデル) とレンダリングするビューを決定します。コードをコントローラーに入れるべきかどうか疑問がある場合は、おそらくそうすべきではありません。コントローラーをスリムに保ちます。
ビュー: ビューには、データ (モデル) を表示するための最小限のコードのみを含める必要があります。多くの処理や計算を行うべきではなく、モデルによって計算 (または要約) されたデータ、またはコントローラーから生成されたデータを表示する必要があります。モデルやコントローラーでは実行できない処理をビューで行う必要がある場合は、コードをヘルパーに配置します。ビューに大量の Ruby コードがあると、ページのマークアップが読みにくくなります。
モデル: モデルは、データ (ユーザー、投稿、アカウント、友達など、サイトを構成するエンティティ) に関連するすべてのコードが存在する場所である必要があります。コードでエンティティに関連するデータを保存、更新、または要約する必要がある場合は、ここに配置します。ビューとコントローラー全体で再利用できます。
pauliephonicの答えに追加するには:
Helper : ビューの作成を容易にする関数。たとえば、ウィジェットのリストを常に繰り返し処理して価格を表示している場合は、それをヘルパーに入れます (実際の表示用のパーシャルと共に)。または、ビューを乱雑にしたくない RJS の一部がある場合は、それをヘルパーに入れます。
MVC パターンは実際には UI のみに関係しており、それ以外には関係ありません。コントローラーはビューを制御しますが、ロジックは制御しないため、複雑なビジネス ロジックをコントローラーに配置しないでください。コントローラーは、適切なビューを選択し、より複雑なものをドメイン モデル (モデル) またはビジネス レイヤーに委任することに関与する必要があります。
ドメイン駆動設計にはサービスの概念があります。これは、多くのさまざまなタイプのオブジェクトを調整する必要があるロジックを貼り付ける場所であり、通常、モデル クラスに自然に属さないロジックを意味します。
私は通常、サービス層をアプリケーションの API と考えています。私のサービス層は通常、私が作成しているアプリケーションの要件に非常に密接に対応しているため、サービス層は、アプリの下位レベルで見られるより複雑な相互作用の単純化として機能します。つまり、サービス層をバイパスして同じ目標を達成できます。しかし、それを機能させるには、さらに多くのレバーを引く必要があります。
ここでは、Rails について話しているのではなく、特定の問題に対処する一般的なアーキテクチャ スタイルについて話していることに注意してください。
ここにはすでに完璧な説明があります。結論として非常に単純な文であり、覚えやすいです。
SMART モデル、THIN コントローラー、DUMB ビューが必要です。
コントローラーに承認/アクセス制御に関連するものを入れてください。
モデルはすべてデータに関するものです。検証、関係、CRUD、ビジネス ロジック
ビューとは、データを表示することです。表示と入力のみ。
コントローラーは、モデルからビュー (およびどのビュー) に、およびビューからモデルにどのデータを送信するかを制御するためのものです。コントローラはモデルなしでも存在できます。
私は、コントローラーを、顧客 (要求) を適切なカウンターに誘導する警備員/受付係と考えるのが好きです。出納係 (ビュー) は、マネージャー (モデル) から答えを受け取ります。次に、警備員/受付係 (コントローラー) に要求を戻し、別の窓口係 (ビュー) に行くように指示されるまで待ちます。別の窓口係 (ビュー) は、マネージャー (モデル) が他の窓口係 (ビュー) の質問に応じて彼らに言った答えを教えてくれます。 .
同様に、窓口担当者 (ビュー) に何かを伝えたい場合、ほとんど同じことが起こりますが、2 番目の窓口担当者がマネージャーがあなたの情報を受け入れたかどうかを教えてくれます。また、管理者にその情報を伝える権限がなかったため、警備員/受付係 (コントローラー) がハイキングをするように言った可能性もあります。
比喩を拡張すると、私の固定観念的で非現実的な世界では、窓口係 (意見) はきれいですが頭が空っぽで、あなたが言うことは何でも信じることがよくあります。行くべきではありません、そしてマネージャーは本当に醜くて意地悪ですが、すべてを知っていて、何が真実で何がそうでないかを知ることができます.
Rails のやり方は、痩せたコントローラーと太ったモデルを持つことです。
適切に分離するのに役立つ1つのことは、「ローカル変数をコントローラーからビューに渡す」アンチパターンを回避することです。これの代わりに:
# app/controllers/foos_controller.rb:
class FoosController < ApplicationController
def show
@foo = Foo.find(...)
end
end
#app/views/foos/show.html.erb:
...
<%= @foo.bar %>
...
ヘルパーメソッドとして利用できるゲッターに移動してみてください。
# app/controllers/foos_controller.rb:
class FoosController < ApplicationController
helper_method :foo
def show
end
protected
def foo
@foo ||= Foo.find(...)
end
end
#app/views/foos/show.html.erb:
...
<%= foo.bar %>
...
これにより、「@foo」に入力される内容とその使用方法を簡単に変更できます。これにより、コントローラーとビューの分離が、複雑になることなく向上します。
まあ、それはロジックが何を処理しなければならないかによって異なります...
多くの場合、コントローラーを小さくして、モデルにより多くのものをプッシュすることは理にかなっています。これにより、モデルが表すデータにアクセスする必要がある場所からこのロジックを簡単に使用できるようになります。ビューにはほとんどロジックを含めないでください。したがって、一般的には、同じことを繰り返さないように努力する必要があります。
また、Google をちょっと調べてみると、何がどこにあるのかについての具体的な例がいくつか明らかになります。
モデル: 検証要件、データ関係、メソッドの作成、メソッドの更新、メソッドの破棄、メソッドの検索 (これらのメソッドの一般的なバージョンだけでなく、赤い人を見つけるなど、頻繁に行っていることがある場合に注意してください)苗字で髪の場合は、そのロジックを抽出して、find_redH_by_name("smith") またはそのようなものを呼び出すだけでよいようにする必要があります)
表示: これは、データの処理ではなく、データの書式設定に関するものです。
コントローラー: ここでデータ処理が行われます。インターネットから:「コントローラーの目的は、ユーザーが要求したアクションに応答し、ユーザーが設定したパラメーターを取得し、データを処理し、モデルとやり取りしてから、要求されたデータを最終的な形で見る。"
それが役立つことを願っています。
テスト、テスト...モデルにできるだけ多くのロジックを配置すると、適切にテストできるようになります。単体テストは、モデルをテストすることによってデータとその形成方法をテストし、機能テストは、コントローラーをテストすることによってデータがルーティングまたは制御される方法をテストするため、データが存在しない限り、データの整合性をテストすることはできません。モデル。
j