MVC：ビジネスロジックを配置する場所
まず第一に、これに関する多くの質問を見てきましたが、その背後にある十分な推論はありません。私の質問が十分ではなく、削除する必要がある場合、私は理解します。
たとえば、 this を調べたところ、45以上の賛成の回答があり、ビジネスロジックをモデルに入れることを勧めていますが、これはかなり論理的に聞こえます。
ただし、コントローラーですべてのBLを完全に使用した最初の大きなプロジェクトは、これらのことを疑問視せず、MVCを選択した場合に自動的に追加されるAccountControllerでどのように実行されるかを調べたためですフォーム認証。すべてのメソッドには、BLが詰め込まれています。または多分それは追加することが可能であったコードの最小量であり、私は物事を見落としていますか？
ユーチューブの人が私に、彼のモデルにすべてのロジックを入れることで彼が正しいかどうか尋ねました。それから私は彼が正しいかもしれないと考え始めました！？
だから、結局のところ、ビジネスロジックをどこに置くのですか？それがモデルクラスにある場合、どのくらいのコードが健全な量と見なされるべきですか？コントローラーにあるメソッド？最大でコントローラーのモデルからメソッドを呼び出してからビューに戻る1行ですか？
いくつかの理由で、モデルにドメインロジックを配置することを好みます。
モデルにはUIコードが含まれていないため、テストが簡単です。可能な限り、UIコードを記述する前に、完全に機能する（完全なテストカバレッジを意味する）モデルを作成するのが好きです。コントローラーは、モデルが正しいことを行っていることを信頼し、UIの懸念に対処するだけです。
コントローラにドメインロジックを配置すると、異なるアプリ間で、または異なるコントローラ間で共有することは簡単ではありません。
私はモデルをきれいに保つのが好きですプロパティだけでビジネスロジックはありません。コントローラーに依存関係を挿入することは常に良いことだと思います。これらの依存関係には、モデルで実行するロジックが含まれています。可能な限り単一の責任原則を遵守したいので、大量のメソッドを持つモデルが非常に急速に肥大化することがわかりました。両方に長所と短所があります。多くの依存関係を注入するとオーバーヘッドが発生しますが、単独でテストでき、クラスをシンプルに保つことができ、無駄のないコントローラーができあがります。私のロジックはクラスのメンバーとしてモデルに実際には存在していませんが、それでもビジネスロジックです。 Httpcontextのようなm笑的なものは悪夢であり、不要であるため、コントローラーでビジネスロジックを定義しない傾向があります。
businessロジックは問題ドメインに属し、問題ドメインに属するものはすべてMVCのmodelになります。
controllerは、モデルからビューにデータを渡し、ビューからモデルにデータを戻す役割を果たします。したがって、コントローラーは、ユーザーの操作内容と、プログラムが問題の状態をモデル化して保存する方法との間の橋渡しをします。 配管、いわば。
ここで重要なのは、ビジネスロジックと配管ロジックの違いです。私の意見では、自動生成されたアカウントコントローラーが行うことは、主に配管であり、実際のビジネスロジックではありません。配管ロジックは必ずしも短いわけではないため、人為的な制限（「コントローラーでの呼び出しの最大数X」など）を課す必要はありません。
このトピックについては混乱があるようです。ほとんどの場合、人々はMVCパターンをN層アーキテクチャとどちらかまたは両方の状況として混同する傾向があるようです。現実には、2つのアプローチを一緒に使用できますが、一方は他方に依存せず、どちらも必要ではありません。
N層アーキテクチャは、アプリケーションを複数の層に分離することに関係しています。簡単な例は、アプリケーションがプレゼンテーション層、ビジネスロジック層、およびデータアクセス層に分割される場合です。
MVCは、アプリケーションのプレゼンテーションレイヤーを扱うデザインパターンです。プレゼンテーション層からビジネスロジックとデータアクセスロジックを分離することなく、MVCアプローチに従ってアプリケーションを設計することは完全に可能であるため、最終的に単一層設計になります。
その結果、アプリケーションを階層に分離せずにMVCアプローチを採用している場合、ビジネスルールのビットとロジックの残りの部分が混在するデータアクセスロジックを含むモデル、ビュー、コントローラーになります。
定義により、N層アーキテクチャでは、プレゼンテーション層はビジネスロジック層とのみ通信できると想定されているため、MVCコンポーネントはいずれもビジネスロジック層とのみ通信できることを保持する必要があります。
プレゼンテーションを伴わない、したがってプレゼンテーション層ではないアプリケーションを構築している場合は、MVCパターンについて心配する必要はありません。ただし、プレゼンテーション層が含まれていなくても、アプリケーションを複数の層に分割し、N層の設計に従うこともできます。
私のチームは、webforms（asp.net）からmvcに移行したときに多くの研究を行い、次の構造を思い付きました。私によると、それはアプリケーションの大きさについてではありません。コードをクリーンで明確に保つことについてです。
DALProject
AccountsDAL.cs --- > Calls SP or any ORM if ur using any
BLLProject
AccountsBLL.cs ---> Calls DAL
WebProject
Model
AccountsModel --- > Contains properties And call BLL
Controllers
IndexController ---> Calls Models and returns View
Views
Index
Controllersは、モデルとビューの間のデータの受け渡しを担当する必要があります。それ以外は、不必要なコードがあってはいけません。たとえば、ロギングする場合は、コントローラーではなくモデルレベルで行う必要があります。
一般的に、ビジネスロジックはMVCプレーヤーのいずれにも存在すべきではありません。コントローラーのアクションによってのみ消費されるはずです。
多くの人が言及したように、クライアントにとらわれない再利用可能なコンポーネントのセットとして、ビジネスロジックをホストするライブラリを作成することが最善です。
このようにすると、ソフトウェアの再利用性、互換性、スケーラビリティ、およびテスト容易性が大幅に向上します。また、特定のフレームワーク機能への依存を減らし、より新しい/異なるテクノロジーへの移行を容易にします。
私たちのビジネスロジックをスタンドアロンのアセンブリに抽象化することは、長年にわたって非常に役立ちました。その後、ビジネスロジックは、事実上すべての.NETテクノロジー（ASP.NET MVC/API/Core、WPF、Win Forms、WCF、UWP、WF、コンソールなど）で使用できます。
さらに、ビジネスルールと検証ロジックを処理して.NET MVCフレームワークへの依存性を減らす中間層が好きです。たとえば、.NET MVC検証ヘルパーの使用を避け、代わりに独自のものに依存しています。これは、.NETテクノロジーからビジネスロジックを簡単に使用できるようにするもう1つの要因です。
このように中間層を論理的に設計することで、この物理アーキテクチャを簡単に実現できました。
それは Peasy.NET で書かれており、長年にわたって私たちに役立っています。実際、私たちはそれをオープンソース化することにしました。
中間層がどのように見えるかについて誰かが興味を持っている場合、クライアントに依存しないビジネス層の sample があります。また、複数の.NETクライアント（ASP.NET MVC、Web Api、およびWPF）による消費量も示します。
これが誰かを助けることを願っています！
私もモデルをきれいに保つのが好きです（@Mark Walshを参照）。コントローラーに埋め込まれたロジックを再利用できないという問題は、依存性注入によって簡単に解決できます。または、多すぎると思われる場合は、ビジネス/ドメインロジックをインターフェイスで公開し、コントローラーでファサードパターンを使用します。そうすれば、必要な機能を取得できますが、コントローラーとモデルの両方をきれいに保ちます。
Ahanusaが書いたように、ビジネスロジックを別のDLLまたは別のディレクトリに置く必要があります。
ビジネスロジックを実行するクラスを置くモデルとコントローラーの同じレベルで、Logicsという名前のディレクトリをよく使用します。
このようにして、モデルとコントローラーの両方をきれいにしました。
また、モデルをきれいに保つことを好みます。 MVCコントローラーは、呼び出しを行うためだけに使用する必要があり、清潔に保つ必要もあります。そのため、再利用性、機密性、関連性に応じて、ビジネスロジックを記述できます。
1.WebApi Controller： webapiコントローラーを使用する利点は、これらを後でサービスとして他のデバイスに公開して、コードを再利用できるようにすることです。
2。BAL/Common commonent：特定の使用法があり、APIとして公開できないロジックがいくつかあり、このクラスにプッシュできます。
。リポジトリ：データベースに関連するすべてのクエリがリポジトリに追加されます。すべての機能（CRUD操作）または各テーブルの特定のリポジトリを実装する汎用リポジトリがあります。実行する操作に応じて。
私が持っている一般的な答えは、ビジネスロジックは通常2つのカテゴリに当てはまるということです。
オブジェクト指向ビジネスロジック：（モデル内の）オブジェクトとしてモデル化され、通常はリポジトリとして挿入されます。
手続き型ビジネスロジック：コントローラーに挿入できるインターフェイスを備えたサービスに入ります。
コントローラーロジック：ロジックコントロールコマンドを受信してモデル/サービスに渡す方法、そしてそれらの結果をビューに渡す方法。
コントローラーにはビジネスロジックを含めないでください。これは、controllingの設計パターンの非常に具体的な部分です。ユーザーインターフェースがビジネスロジック（または問題がより手続き型の場合はサービス）を処理するモデルに入力を渡す方法。
MVCについての質問であることは知っていますが、ここで紹介する例（Web API）は役に立つと思います。
私は最初のWeb APIを開発しており、他のアプリケーションのビジネスロジックを再利用しています。具体的には、外部DLLから取得されるため、APIを使用して、SAPソリューションと「対話」し、POから要求を受信し、応答を送信します。
コントローラーにロジック（実装済み）を配置するにはどうすればよいですか？必要ありません。私のコントローラーは、データを送り返すために、リクエストの受信、検証、および応答の作成のみを行います。
私はViewModelクラスを使用しており、それらに必要なのは、TransferObjects（外部DLLから取得）から情報を読み取り、ViewModelに変換するためのマッピング関数だけです。
私は自分のアプリケーション（この場合はWeb API）がビジネスロジックを保持していることに満足していません。この方法では再利用性が失われると思います。
私は、ビジネスロジックをコントローラーに注入する依存関係として扱っています。
レガシーで多くのリファクタリングを行って単体テスト可能なソリューションを提供しましたが、多くのインターフェイスを作成し、いくつかのデザインパターンをレガシーに実装してこのソリューションを提供する必要がありました。
私の観点では、ビジネスレイヤーはアプリケーションの一部である必要があり、できれば別のクラスライブラリであることが必要です。そのため、実際の分離の概念がアプリケーションに実装されます。
もちろん、CORE（ビジネス）がアプリケーション（API/WebSite）の場合、ビジネスルールはMVCクラスに実装されます。しかし、将来、新しいアプリを開発する必要があり、いくつかのビジネスルールが同じ場合、両方のアプリケーションに実装された同じロジックを維持するだけでは多くの問題が発生するに違いありません。