多くの意見を聞いていますが、コントローラーにどのような種類のロジックを含めるべきかについての一般的なルールはありますか?
私はデータアクセスと更新にリポジトリを使用していますが、コントローラーで更新するアクションメソッド(たとえば、FormCollectionオブジェクトなど)でモデルパラメーターを取り込んでから、更新のためにリポジトリに渡すのはどうでしょうか。
明確なノーノーはありますか?
ありがとう
多くの意見を聞いていますが、コントローラーにどのような種類のロジックを含めるべきかについての一般的なルールはありますか?
私はデータアクセスと更新にリポジトリを使用していますが、コントローラーで更新するアクションメソッド(たとえば、FormCollectionオブジェクトなど)でモデルパラメーターを取り込んでから、更新のためにリポジトリに渡すのはどうでしょうか。
明確なノーノーはありますか?
ありがとう
私は通常、モデルとビューの間の分離を可能にする方法でコントローラーを設計し、それらが互いの存在を無視できるようにします。
問題は、境界線にある問題に関して、モデルの責任とコントローラーの責任を定義することです。エンティティを DB に永続化することがコントローラーのタスクであると主張する人は誰もいませんが、たとえば検証について話すと、さらに物議を醸すことになります。
入力の検証については、私の個人的なアプローチは、エンティティがモデルに渡されたときに既に有効であるという前提/制約を使用して、コントローラー側で実行することです。この傾向は、コントローラー側ですぐに使用できる検証を提供する一部の MVC フレームワーク (つまり Struts) によって促進されますが、たとえば、モデルを別のコンテキスト (たとえば、 Web サービス) であり、検証ルールは以前のコントローラーに関連付けられています。
私はあなたの調査をお勧めしますが、個人的な経験からの小さなアドバイスがあります: それについてあまり考えないようにしてください. この種の問題は、宗教戦争と、さまざまなアプローチの擁護者の無意味な頑固さによって肥大化しています。現実の世界では、最終的にこれらすべての設計上の問題が厳しい事実によって台無しにされ、副社長が昼食時間前にそれを求めているため、15 分で機能する何かを行うように求められるだけです。