コントローラーレイヤーに存在できるビジネスロジックの量はどのくらいですか？
アプリケーションのコントローラーコードにビジネスロジックが含まれている場合があります。これは通常、モデルから呼び出すメソッドやそれらに渡す引数を区別するロジックです。
この別の例は、一連のビジネスルールに従って、モデルから返されたデータをフォーマットまたはサニタイズするために機能する、コントローラーに存在するユーティリティ関数のセットです。
これは機能しますが、災害でいちゃつくのではないかと思います。コントローラーとモデル間で共有されるビジネスロジックがある場合、2つのレイヤーは分離できなくなり、コードを継承する誰かが、ビジネスロジックに関連するコードの場所の不均一性によって混乱する可能性があります。
私の質問は、コントローラーでどのくらいのビジネスロジックを許可する必要があるか、また、どのような状況で許可されているかということです
理想的にはなし
しかし、それが常に可能であるとは限りません。 20％や10行などの具体的な数値を示すことはできません。これは、答えられない点に対して主観的なものです。少し曲げる必要があるデザインパターンと状況の使用方法を説明できます。
私の考えでは、それは完全にアプリケーションの目的次第です。シンプルなREST投稿先のAPIを作成しますか？完全な分離やパターンを忘れてください。1時間以内に作業中のバージョンを作成できます。もっと大きなものを作成しますか？おそらくそれで作業するのが最善です。
個別に含まれるシステムを構築することが目標です。 2つのシステムがどのように相互作用するかに固有のビジネスロジックを作成し始めると、それが問題になります。詳細に調べないと、私は意見を述べることができません。
デザインパターンは型であり、主なコードと適切に記述されたコードに基づいて、それらに厳密に準拠するようなものもあります。パターンに厳密に従うと、おそらくbadコードは得られませんが、さらに時間がかかり、より多くのコードを書く可能性がありますコード。
設計パターンは柔軟であり、yourのニーズに合わせて調整します。曲げすぎると壊れます。 必要なものを理解するそして、それに最も近いデザインパターンを選択します。
出来るだけ少なく。できればなし。
コントローラは、要求の受け入れ、要求を処理するための正しいドメインサービスへの要求、および正しいビューへの応答の引き渡しに関係する必要があります。
そのプロセスでは、すべての「ビジネスロジック」がドメインサービスに存在する必要があります。
ドメインオブジェクトを取得してそれらからビューモデルを作成する機能がある場合、それはコントローラーと合理的に共存できます。しかし、それは対応するビューのために存在するコードonlyでなければなりません。データサニタイズに関するビジネスレベルのルールがある場合、それはドメイン/サービスレベルに存在する必要があります（適切な単体テストを使用）。
「ビジネスロジック」という用語は、これが何を意味するかについて人々が異なる意見を持っているため、しばしば混乱するものです。私の考えでは、「ビジネスロジック」という用語は2つの領域をカバーしています。
- ドメインロジック
- アプリケーションロジック
ドメインロジックは、ビジネスが関連するコア領域に関連するロジックであるため、会計士向けのアプリケーションを作成する場合、税規則、簿記規則などはドメインロジックの一部です。
アプリケーションロジックは、コンピュータープログラムを実行しているという事実に関連するロジックです。これには、CSVインポートエクスポート、ウィザードなどが含まれます。忘れたパスワードメールの作成なども含まれます。
コントローラー層に配置できる「ビジネスロジック」の種類は、アプリケーションロジックです。たぶん、すべてのアプリケーションロジックがそこに行くべきではありません。ただし、ドメインロジックをコントローラーレイヤーに配置しないでください。それは明らかにドメイン層にあるはずです。
あなたはデータをフォーマットまたはサニタイズするロジックについて話していました。書式設定は間違いなくアプリケーションロジックでなければなりません。一方、データのサニタイズがドメインルールに基づいている場合、サニタイズはドメインロジックになる可能性があります。それはコンテキストに依存します。
コントローラはドメインロジックを非常に軽くする必要があります。
コントローラーは、抽象化されたサービス/リポジトリレイヤーを介してデータストアからレコードを取得する、同じ（または関連する）サービスによってデータをデータストアに戻すなどのタスクを委任する必要があります。これらの操作間のメカニズムと細かい作業については、通常、コントローラー以外の場所に属します。
小さなデータサニテーションメソッドをコントローラーに追加して、データをストアに保存することがよくあります。これは効果的な解決策ですが、コントローラーの意図する役割にうまく適合しません。理想的には、モデルを変更、検証、または解析するものはすべて、モデル自体の内部ではないとしても、その近くに発生する必要があります。たとえば、モデルオブジェクトを保存する前に「クリーンアップ」する必要がある場合は、モデルに、またはモデルの保存を処理するサービスの一部としてSanitizeInputs（）メソッドを使用することを検討してください。
実用的な観点から見ると、パターンに準拠した適切なアプローチがないものを実行しようとすると、コントローラーのロジックまたはモデルのコントローラーの動作になってしまうことがわかりました。背後に大きなインフラストラクチャがないアプリを作成している場合は、二重になります。
どちらの方法でもかまいませんが、私は通常、奇妙なビットが複数のコントローラーアクションに現れる可能性があるかどうかを考えます。それが不明確な場合は、ある場所で他の場所よりも「フィッティング」されているかどうかを考えます。コントローラーに近づけないようにするために、通常はモデルに配置することに失敗しました（小さいコントローラーと強力なデータオブジェクト、YMMVの個人的な好み）
3番目のオプションは、ユーティリティアイテムを別のユーティリティクラスとして参照することですが、これはパターンに対してもある程度反対します。
また、パターンに厳密に従っていないからといって、必ずしも災害でいちゃつくとは限りません。このプロジェクトで大量のコードが再利用されることを本当に期待しているのでない限り、プロジェクトがそれ自体と一貫していることについてはずっと心配します（つまり、場所を選択したら、これらのビットを配置する場所をフリップフロップにしないでください）。何らかの理由でプロジェクトの途中の一部を保存したいという書き直しよりも。一般的なパターンから逸脱した場所と理由を文書化/コメントし、このアプリケーションの予想されるパターンを定義します。
MVCは、ある時点で確立されたパターン自体からの逸脱でした。
プログラミングにおける他の多くの興味深い概念と同様に、MVCは、特定のシナリオを実装するために、近いまたは類似した戦略のファミリーに構造と焦点をもたらす強力なパラダイムです。
他の多くのプログラミング概念と同様に、MVCは現実を簡素化し、細部を破棄し、従うべき粗雑なワイヤーフレームモデルを提供します。現実の他の多くの単純化と同様に、人間の心に見られるように、それは構造をカオスに持ち込むのに役立ちます。
それでも、他の多くのプログラミング概念と同様に、MVSは現実を単純化したものにすぎません。それは完璧ではなく、完全ではありません。これが、現実世界のシナリオを単純化しすぎたモデルに適合させることができない理由です。したがって、これと同様の多くの質問が発生します。
どのくらいのロジックをコントローラーに入れる必要がありますか？
ビューに条件付きロジックを含めるかどうか
ビジネスエンティティに直接見つからない追加データをモデルに含める必要があるかどうか。
これらはすべて、MVCの概念的なアイデアに正確かつ完全に適合するようにコードを調整しようとして生まれた質問です。
あなたへの私の答えは、しようとしないことです。 MVCは構造を提供します。この基盤を中心にアプリケーションを構築しますが、完全に適合するとは期待しないでください。偏差がありますが、それは正常です。監視して、制御下に置いてください。