MVC：ビジネスロジックをどこに置くか？[閉まっている]

まず第一に、私はこれについて多くの質問を見てきましたが、その背後にある十分な理由はありません。私の質問が十分ではなく、削除する必要がある場合は、理解します。

私は、を見て撮影している例えば、これと45+は答え、彼はかなり論理的に聞こえるモデルにビジネスロジックを置くことを知らせる言うまで投票しました。

ただし、最初の大規模なプロジェクトでは、すべてのBLをコントローラーで完全に実行しました。これらのことについては質問せずAccountController、フォーム認証付きのMVCを選択した場合に自動的に追加されるでどのように実行されるかを確認したためです。すべてのメソッドはBLでかなり詰め込まれているように見えます。それとも、追加できるコードの量が最も少なく、見落としているのでしょうか。

YouTubeの人が、すべてのロジックをモデルに組み込んで正しいかどうかを尋ねましたが、最初はそうではありませんでした。それから私は彼が正しいのではないかと思い始めました！？

それで、結局のところ、私は私のビジネスロジックをどこに置くのですか？それがモデルクラスにある場合、コントローラーにあるメソッドでどのくらいのコードを正常な量と見なす必要がありますか？コントローラーのモデルからメソッドを呼び出してからビューに戻るための1行ですか？

いくつかの理由から、モデルにドメインロジックを配置することを好みます。

1. モデルにはUIコードが含まれていないため、テストが簡単です。可能な限り、UIコードを作成する前に、完全に機能する（完全なテストカバレッジを意味する）モデルが必要です。コントローラは、モデルが正しいことを実行していることを信頼し、UIの問題に対処するだけです。

2. ドメインロジックをコントローラーに配置すると、異なるアプリ間、または異なるコントローラー間でさえ共有するのは簡単ではありません。

モデルをクリーンに保つのが好きです。つまり、プロパティだけでビジネスロジックはありません。私は常に依存関係をコントローラーに注入するのが良いと思います。これらの依存関係には、モデルで実行するロジックが含まれています。私は可能な限り単一責任の原則に従うのが好きで、たくさんのメソッドを持つモデルはすぐに肥大化することがわかります。両方に長所と短所があります。多くの依存関係を注入することにはオーバーヘッドがありますが、単独でテストすることができ、クラスを単純に保つことができ、最終的にはよりスリムなコントローラーになります。私のロジックはクラスのメンバーとしてモデルに実際には存在しませんが、それでもビジネスロジックです。Httpcontextのようなモックは少し悪夢で不必要なので、コントローラーでビジネスロジックを定義しない傾向があります。

ビジネスロジックは、問題のドメインに属していると、問題のドメインに属しているすべてのものは、に行くモデルMVCインチ

コントローラは、ビューに、ビューの背面からモデルへのモデルからのデータを渡すための責任を負わなければなりません。したがって、コントローラーは、ユーザーが操作するものと、プログラムが問題の状態をモデル化して保存する方法との間の架け橋になります。配管、いわば。

ここで重要なのは、ビジネスロジックと配管ロジックの違いです。私の意見では、自動生成されたアカウントコントローラーが行うことは、ほとんどが配管であり、実際にはビジネスロジックではありません。配管ロジックは必ずしも短いとは限らないため、人為的な制限を課す必要はありません（「コントローラーで最大X回の呼び出し」など）。

私のチームは、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

コントローラーは、モデルとビューの間で受け渡されるデータを担当する必要があります。それ以外は、不要なコードがあってはなりません。たとえば、ログを記録する場合は、コントローラーではなくモデルレベルで実行する必要があります。

このトピックに関しては混乱があるようです。ほとんどの場合、MVCパターンをN層アーキテクチャと混同する傾向があるようです。現実には、2つのアプローチを一緒に使用できますが、一方は他方に依存せず、どちらも必要ありません。

N層アーキテクチャは、アプリケーションを複数の層に分離することに関係しています。簡単な例は、アプリケーションがプレゼンテーション層、ビジネスロジック層、およびデータアクセス層に分割されている場合です。

MVCは、アプリケーションのプレゼンテーション層を扱うデザインパターンです。ビジネスロジックとデータアクセスロジックをプレゼンテーション層から分離することなく、MVCアプローチに従ってアプリケーションを設計することは完全に可能であり、最終的には単一層の設計になります。

その結果、アプリケーションを層に分割せずにMVCアプローチに従っている場合、ビジネスルールとデータアクセスロジックのビットが残りのロジックと混合されたモデル、ビュー、およびコントローラーになってしまいます。

定義上、N層アーキテクチャでは、プレゼンテーション層はビジネスロジック層とのみ通信できると想定されているため、MVCコンポーネントはビジネスロジック層とのみ通信できるようにする必要があります。

プレゼンテーションを含まない、つまりプレゼンテーション層を含まないアプリケーションを構築している場合は、MVCパターンを気にする必要はありません。ただし、プレゼンテーション層が含まれていなくても、アプリケーションを複数の層に分割して、N層の設計に従うことができます。

一般的に言って、ビジネスロジックはMVCプレーヤーのいずれにも存在すべきではありません。それは消費されるべきですコントローラのアクションによってがあります。

多くの人が言及しているように、クライアントに依存しない再利用可能なコンポーネントのセットとしてビジネスロジックをホストするライブラリを作成するのが最善です。

このようにすると、ソフトウェアの再利用性、互換性、スケーラビリティ、およびテスト容易性が大幅に向上します。また、特定のフレームワーク機能への依存を減らし、新しい/異なるテクノロジーへの移行を容易にします。

ビジネスロジックをスタンドアロンのアセンブリ（または複数のアセンブリ）に抽象化することは、長年にわたって私たちに役立ってきました。私たちのビジネスロジックは、事実上すべての.NETテクノロジ（ASP.NET MVC / API / Core、WPF、Win Forms、WCF、UWP、WF、コンソールなど）で使用できます。

さらに、中間層がビジネスルールと検証ロジックを処理して、.NETMVCフレームワークへの依存を減らすことができます。たとえば、.NET MVC検証ヘルパーの使用を避け、代わりに独自のヘルパーに依存します。これは、.NETテクノロジからビジネスロジックを簡単に利用できるようにするもう1つの要素です。

このように中間層を論理的に設計することで、この物理アーキテクチャを簡単に実現できます。

それはPeasy.NETで書かれ、何年にもわたって私たちに役立ってきました。実際、私たちはそれをオープンソース化することに決めました。

中間層がどのように見えるかについて誰かが興味を持っている場合は、クライアントにとらわれないビジネス層のサンプルを次に示します。また、複数の.NETクライアント（ASP.NET MVC、Web Api、およびWPF）による消費についても説明します。

これが誰かを助けることを願っています！

ビジネスロジックは、モデルビューまたはコントローラーに配置しないでください。別のビジネスロジック層が必要です。この層の唯一の目的は、ビジネスロジックを処理することです。これは、SOLIDとより一致しています。

ビジネスロジックをMVまたはCに配置すると、テスト/再利用が難しいコードになってしまいます。

モデルにロジックを配置するのはどうですか？

それは悪い解決策です。

オブジェクトがオブジェクトに依存している依存関係地獄に行き着きます。

完全に単純な関数がある場合でも、それを呼び出すにはすべての依存関係を満たす必要があります。

また、原因となり、不要と未使用データが理由もなく周りに渡されます。これは、パフォーマンスの低下によってはパフォーマンスにも影響を与える可能性があります。

また、単純な関数をテストするためだけに複数のオブジェクトをモックする必要があるため、単体テストはa **で苦痛になることにも言及する必要があります。

適用可能なクリーンコードの原則

1. クラス/関数は、仕事を成し遂げるために必要なものだけを取ります。
2. 関数は、可能であれば3つ以下のパラメーターを取る必要があります
3. クラス/関数/変数にインテリジェントに名前を付けます（Microsoftの標準に従います）
4. ビジネスロジックをモデルビューまたはコントローラーに結合しないでください

コントローラー

コントローラでは、依存性注入を使用してビジネスロジック層を注入できるはずです。コントローラが情報をビジネスロジック層にルーティングするためにのみ使用されていることを確認してください。コントローラには、ビジネスロジックを直接含めるべきではありません。検証はすべてIValidatable、モデルで処理する必要があります。すべてのビジネスロジックは、別のレイヤーにルーティングする必要があります。

私が持っている一般的な答えは、ビジネスロジックは通常2つのカテゴリに当てはまるということです。

オブジェクト指向ビジネスロジック:(モデル内の）オブジェクトとしてモデル化され、通常はリポジトリとして注入されます。

手続き型ビジネスロジック：コントローラーに挿入できるインターフェイスを備えたサービスを利用します。

コントローラロジック：コマンドを受信して​​モデル/サービスに渡す方法と、それらの結果をビューに渡す方法を制御するロジック。

コントローラにはビジネスロジックがあってはなりません。これは、ユーザーインターフェイスがビジネスロジック（または問題がより手続き的な性質の場合はサービス）を処理するモデルに入力を渡す方法を制御するためのデザインパターンの非常に特殊な部分です。

モデルもきれいに保つのが好きです（参照：@Mark Walsh）。コントローラに埋め込まれたロジックを再利用できないという問題は、依存性注入によって簡単に克服できます。または、依存性注入が多すぎると思われる場合は、インターフェイスを介してビジネス/ドメインロジックを公開し、コントローラのファサードパターンを使用します。そうすれば、必要な機能を手に入れることができますが、コントローラーとモデルの両方をきれいに保つことができます。

また、モデルをクリーンに保ちたいと思います。MVCコントローラーは、呼び出しを行うためにのみ使用する必要があり、クリーンに保つ必要もあります。したがって、その再利用性、感度、および関連性に応じて、ビジネスロジックを記述できます。

1.WebApiコントローラー：webapiコントローラーを使用する利点は、これらをサービスとして後で他のデバイスに公開して、コードを再利用できるようにすることです。

2. BAL /共通共通：特定の使用法があり、APIとして公開できないロジックがいくつかあり、このクラスでプッシュできます。

3.リポジトリ：データベースに関連するすべてのクエリがリポジトリに追加されます。すべての関数（CRUD操作）を実装する汎用リポジトリー、または各テーブルの特定のリポジトリーが存在する場合があります。実行する操作によって異なります。

ahanusaが書いたように、ビジネスロジックを別のDLLまたは別のディレクトリに配置する必要があります。
私はよく、ビジネスロジックを実行するクラスを配置するモデルとコントローラーの同じレベルでLogicsという名前のディレクトリを使用します。
このようにして、モデルとコントローラーの両方をクリーンにします。

MVCについての質問であることは知っていますが、私が提供している例（Web API）は役立つと思います。

私は最初のWebAPIを開発しており、他のアプリケーションのビジネスロジックを再利用しています。具体的には、外部DLLから取得されるため、私のAPIは、SAPソリューションと「対話」し、POから要求を受信し、応答を送り返すために使用されます。

ロジック（すでに実装されている）をコントローラーに配置するにはどうすればよいですか？私はそれを必要としません。私のコントローラーは、要求を受信して​​検証し、応答を作成してデータを送り返すだけです。

私はViewModelクラスを使用しており、TransferObjects（外部DLLから取得）から情報を読み取り、ViewModelに変換するために必要なのはマッピング関数だけです。

私は自分のアプリケーション（この場合はWeb API）がビジネスロジックを保持することに不安を感じています。このようにすると、再利用性が失われると思います。

私は自分のビジネスロジックをコントローラーに注入する依存関係として扱っています。

ユニットテスト可能なソリューションを提供するためにレガシーで多くのリファクタリングを行いました。このソリューションを提供するには、多くのインターフェイスを作成し、レガシーにいくつかのデザインパターンを実装する必要がありました。

私の見解では、ビジネス層はアプリケーションの一部、できれば別のクラスライブラリにある必要があります。したがって、アプリケーションに実際の分離の概念が実装されます。

もちろん、CORE（ビジネス）がアプリケーション（API / WebSite）の場合、ビジネスルールはMVCクラスに実装されます。しかし、将来、新しいアプリを開発したいが、いくつかのビジネスルールが同じである場合、両方のアプリケーションに実装された同じロジックを維持するためだけに多くの問題が発生することは間違いありません。