MVC：ビジネスロジックがどこに属しているかについて明確な答えがありますか？

Question

私は現在、パターンの経験が限られているにもかかわらず、C＃MVCアプリケーションをリファクタリングしようとしています。被験者の周りを読んで、私はベストプラクティスのために逆らって反対意見を絶えず抱えているようです。

私の最大の問題は、コントローラーに多すぎるものがあることです。それらは機能しますが、再構成やテストが困難なビジネスロジックでいっぱいです。モデルはほとんどが薄いDTOです。では、この有用なビジネスロジックを再構築してテストするために、どこから始めましょうか？

多くの人はそれがgo in the modelであると言います。しかし、あなたはそれを言っている人がいます。​​。そして、モデルcontaining data and NOTHING ELSEの原理がパターンの基本であることを伝える他の人たち。

次に、4番目のタイプのクラス「ViewModel」に入るべきだと言う人がいます。今私はWPFでMVVMに取り組んできましたが、私はこのパラダイムに精通しています。しかし、それをMVCに追加するだけで、パターンの指示に盲目的に従うよりも、他の場所で行われる多くの作業を複製するように見えます。

さらに別のオプションは、何らかのヘルパークラスに入れることです。これは一般的な提案ですが、私はリンクしません。しかし、それを行うことは、単一のコントローラに機能を提供する以外に存在することのない別のクラスを無駄に使用するように思えます。そして、それはOOP原則の根本的な違反に見えるでしょう。

これには「正しい」答えがありますか？もしそうなら、そんなに混乱するのはなぜですか？もしそうでなければ、あなたはこの意見で最善の解決策をどのように評価するのでしょうか？

Answer 1

私には、MVCのMはビューモデルを表し、ビューが作業を行うために必要なデータを含んでいるため、ビューはできるだけダム状態に保たれます。

このビューモデルはコントローラで作成され、ビューに渡されますが、コントローラのロジックを小さく保つ必要があるため、ここではビジネスロジックは必要ありません。

このビジネスロジックは、WCFで公開されているリモートサービス、Web API、またはWebサイトのメソッドを含むクラスライブラリだけに属します。

ので、要約：

1. コントローラはモデルの形式でデータを取得するためのサービスを呼び出します。ビジネスロジックはこれらのサービスの内側にあり、返されるモデルは単なるPOCOです。
2. コントローラは受信したモデルに基づいてビューモデルを作成します。このモデルには、ビューに最適な形式のプロパティが含まれています。
3. コントローラはビ​​ューモデルをビューに渡します。ビューモデルはビューモデルを使用して構築されます。

Answer 2

"正しい"答えがあるとは思いません。私は、それがすべて優先され、データ操作がどれほど複雑であると信じています。

私の会社では、組織目的でヘルパークラス/サービスを使用しています。私たちのコントローラには、モデルを取り込み、操作し、ビューに戻す以外の機能は含まれていません。

私たちは膨大な量のデータ操作をしており、コントローラでそれを行うには恐ろしい混乱があります。

ほとんどの人は、コントローラーに論理がないはずがないことに同意します。違いは、そのロジックがあるべき場所です。私の会社にとっては、それが起こる操作の量が非常に多いので、それをモデル自体に入れるのはばかげているでしょう。大量の操作がなければ、モデルに入れます。

Answer 3

私が現在取り組んでいるプロジェクトでは、私たちはコントローラーをBusiness Logicから無理なく解放してきたので、それらを作業単位に分けています。私はこのパターンが採用され、クライアントなどに応じてUnits of Workを入れ替えることができると信じています。

前回の私が取り組んでいたプロジェクトはすべてコントローラ内にあり、必要に応じて小さな共有ヘルパー。

厳密に正しい方法や不正な方法はないと思います。大部分の時間は、開発者の個人的な好みによると思われる。