コントローラーレイヤーに存在できるビジネスロジックの量。

アプリケーションのコントローラーコードで表されるビジネスロジックがある場合があります。これは通常、モデルから呼び出すメソッドやそれらを渡す引数を区別するロジックです。

これの別の例は、ビジネスルールのセットに従って、モデルから返されたデータをフォーマットまたはサニタイズするために機能するコントローラーに存在するユーティリティ関数のセットです。

これは機能しますが、災害といちゃつくかどうか疑問に思っています。コントローラーとモデル間で共有されるビジネスロジックがある場合、2つのレイヤーは分離できなくなり、コードを継承する人は、ビジネスロジック関連のコードの場所の不均一性によって混乱する可能性があります。

私の質問は、コントローラーでどのくらいのビジネスロジックを許可する必要があるか、また、ある場合、どのような状況ですか？

理想的にはなし

しかし、それは常に可能というわけではありません。20％や10行のようなハードな数値を提供することはできません。これは、回答できない点を主観的に示しています。少し曲げる必要がある設計パターンと状況の使用方法を説明できます。

私の考えでは、それはアプリケーションの目的次第です。投稿する単純なREST APIを構築しますか？きれいな分離やパターンさえ忘れてください。1時間以内に作業バージョンを解約できます。より大きな何かを構築していますか？おそらく作業するのが最善です。

個々に含まれるシステムを構築することが目標です。2つのシステムが相互作用する方法に固有のビジネスロジックの記述を開始する場合、それは問題です。さらに検討することなく、私は意見を述べることはできません。

設計パターンは型であり、主なコードと適切に作成されたコードに基づいて厳密にパターンに準拠するものもあります。厳密にパターンを厳守しても、おそらく悪いコードは得られませんが、より時間がかかり、より多くのコードを書くようになる可能性があります。

設計パターンは柔軟で、ニーズに合わせて調整します。曲げすぎると壊れます。必要なものを把握し、それに最も近いデザインパターンを選択します。

出来るだけ少なく。できればなし。

コントローラーは、要求を受け入れ、正しいドメインサービスに要求を処理するように依頼し、正しいビューに応答を渡すことに注意する必要があります。

そのプロセスでは、すべての「ビジネスロジック」がドメインサービスに存在する必要があります。

ドメインオブジェクトを取得してそれらからビューモデルを作成する機能がある場合、それはコントローラと合理的に共存できます。しかし、それは対応するビューのためだけに存在するコードでなければなりません。データのサニタイズに関するビジネスレベルのルールがある場合は、ドメイン/サービスレベルに存在する必要があります（適切な単体テストを使用）。

「ビジネスロジック」という用語は、人々がこれが何を意味するかについて異なる意見を持っているため、しばしば混乱を招くものです。私の考えでは、「ビジネスロジック」という用語は2つの領域をカバーしています

• ドメインロジック
• アプリケーションロジック

ドメインロジックは、ビジネスに関連するコア領域に関連するロジックです。したがって、会計士向けのアプリケーションを作成する場合、税規則、簿記規則などはドメインロジックの一部です。

アプリケーションロジックは、コンピュータープログラムを実行しているという事実に関連するロジックです。これには、CSVインポートエクスポート、ウィザードなどが含まれます。パスワードを忘れた場合のメールの作成なども含まれます。

コントローラレイヤーに配置できる「ビジネスロジック」の種類は、アプリケーションロジックです。すべてのアプリケーションロジックがそこに行く必要はないでしょう。ただし、ドメインロジックをコントローラーレイヤーに配置しないでください。それは明らかにドメイン層にあるはずです。

データをフォーマットまたはサニタイズするロジックについて話していました。書式設定は、間違いなくアプリケーションロジックでなければなりません。一方、データのサニタイズがドメインルールに基づいている場合、サニタイズはドメインロジックになる可能性があります。それはコンテキストに依存します。

コントローラーは、ドメインロジックを非常に軽くする必要があります。

コントローラーは、抽象化されたサービス/リポジトリレイヤーを介してデータストアからレコードを取得し、同じ（または関連する）サービスによってデータストアにデータを戻すなどのタスクを委任する必要があります。これらの操作間のメカニズムとより細かい作業については、通常、コントローラー以外の場所に属します。

コントローラーにデータを保存する小さなデータ衛生方法を追加することがよくあります。これはデータをストアに保存しますが、これは効果的なソリューションですが、コントローラーの意図する役割にはうまく適合しません。理想的には、モデルを変更、検証、または解析するものはすべて、モデル自体の内部ではないにしても、非常に近くで発生する必要があります。たとえば、モデルオブジェクトを保存する前にモデルオブジェクトを「クリーン」する必要がある場合は、モデル上またはモデルの保存を処理するサービスの一部としてSanitizeInputs（）メソッドを用意することを検討してください。

実用的な観点からは、パターンに準拠した適切なアプローチではないことをしようとすると、コントローラーのロジックまたはモデルのコントローラーの動作が発生することがわかりました。二重に、もしあなたが背後に大きなインフラストラクチャを持たないアプリを書いているなら。

どちらの方法でも実行できますが、通常は、奇妙なビットが複数のコントローラーアクションに表示される可能性があるかどうかを考えます。それが不明な場合は、ある場所で他の場所よりも「フィット」しているのではないかと考えます。コントローラーに入れないようにするために、通常はモデルに入れないことに失敗しました（より小さなコントローラーと強力なデータオブジェクトYMMVの個人的な好み）

3番目のオプションは、ユーティリティ項目を個別のユーティリティクラスとして参照することですが、それは多くの意見ではパターンにいくらか反しています。

また、パターンを厳密に守っていないからといって、必ずしも災害をいじめているわけではありません。このプロジェクトでかなりの量のコードの再利用を本当に期待しない限り、私はプロジェクトがそれ自体と一貫していることをもっと心配します（つまり、場所を選んだら、これらのビットを置く場所にフリップフロップしないでください）何らかの理由でプロジェクトの途中の一部を保存したい書き直しよりも。共通パターンから外れた場所と理由を文書化/コメントし、このアプリケーションに期待されるパターンを定義します。

MVCは、ある時点で確立されたパターン自体からの逸脱でした。

プログラミングにおける他の多くの興味深い概念と同様に、MVCは、特定のシナリオを実装するための類似または類似の戦略のファミリに構造と焦点をもたらす強力なパラダイムです。

他の多くのプログラミング概念と同様に、MVCは現実を単純化し、細部を破棄し、従うべき粗雑なワイヤフレームモデルを提供します。他の多くの現実の単純化と同様に、人間の心に見られるように、構造をカオスにもたらします。

それでも、他の多くのプログラミング概念と同様に、MVSは現実の単純化にすぎません。それは完璧ではなく、完全ではありません。これが、現実世界のシナリオを単純化したモデルに適合させることができない理由です。したがって、これに似た多くの質問が発生します。

• どのくらいのロジックをコントローラーに入れるべきですか？

• ビューに条件付きロジックを含める必要があるかどうか

• モデルにビジネスエンティティで直接検出されない追加データを含める必要があるかどうか。

これらはすべて、MVCの概念的なアイデアに正確かつ完全に適合するようにコードを調整する試みで生まれた質問です。

あなたへの私の答えはしようとしないでください。MVCは構造を提供します。この基盤を中心にアプリケーションを構築しますが、完全に適合するとは思わないでください。偏差がありますが、それは正常です。それらを制御し続けるためにただ見てください。