弊社では、ビジネスロジックへの呼び出しがCRUD操作を実行するためにどこにあるべきかについていくつかの哲学的な議論があります。
モデルはデータ構造で構成されている必要があり、コントローラーがデータの入力を担当する必要があると思います。
私の同僚は、すべての母集団はモデルクラス自体で実行され、コントローラーによって呼び出されるだけでよいと考えています。これにより、コントローラーがすっきりときれいに保たれます（ただし、私の意見では、モデルが乱雑になります）。
彼はまた、Jsonオブジェクトを返す呼び出しは、コントローラーではなくモデルで発生する必要があると考えています。モデルは配列をコントローラーに返し、コントローラーはこれをJsonオブジェクトとして返します。
それぞれにいくつかの異なる長所/短所は何ですか？これを行うための正しい方法または間違った方法はありますか？
すべてのビジネスロジックはモデルに含まれている必要があります。
したがって、各レイヤーの責任は次のとおりです。
最大のメリットの1つは、メンテナンスと（後の）拡張です。一般に：
上記を行うには、適切に機能するために、各レイヤーが他のレイヤーの知識を持っていない必要があります。たとえば、ビューはデータを受信する必要があり、正しく表示するためにデータがどこから来たのかを知る必要はありません。コントローラーは、モデルと対話するために、モデルの基本構造について何も知る必要はありません。モデルは、データの表示方法（フォーマットなど）やワークフローについての知識を持っていない必要があります。
「彼はまた、Jsonオブジェクトを返す呼び出しは、コントローラーではなくモデルで発生する必要があると考えています。モデルは配列をコントローラーに返し、コントローラーはこれをJsonオブジェクトとして返します。」
いいえ。モデルはデータをフォーマットしないでください。また、フォーマットされたデータを読み取ってはなりません。それはモデルを汚染し、地獄のレベルに移動していますbusiness logic = display logic。
JSON（出入り）は単なる別の見方です。だから外出：
Data Store -> Model -> Controller -> View
入ってきます：
View -> Controller -> Model -> Data Store
参考までに、私の第一言語はPHPなので、これをすべて一粒の塩で取ることができます。
MVCおよびMVCに触発されたパターンのビジネスビジネスロジックは、モデルレイヤーに含まれている必要があります。はい、モデルはクラスやオブジェクトではなく、レイヤーであると想定されています。
上記のロジックのほとんどはドメインオブジェクトに存在しますが、一部はサービスになります。サービスは、モデルレイヤーの「トップレベル」構造のようになり、プレゼンテーションレイヤー（ビューとコントローラー）がモデルレイヤーと対話します。
サービスは、ストレージの抽象化（データマッパー、データアクセスオブジェクト、作業単位および/またはリポジトリ）とドメインオブジェクト間の相互作用も促進する必要があります。これらの構造は、永続的および一時的なストレージを処理し、データの整合性を処理します。
この種の分離により、コードベースの保守とテストの両方が簡素化されます。データベース（または他の形式のストレージ）に触れることなく、ドメインロジックを簡単にテストできるようになります。
コントローラー（および他のMVVMおよびMVPパターンからの同等の構造）は、ユーザーの要求から情報を抽出し、モデルレイヤーの状態（サービスを操作することによって）とビューを変更する必要があります。
MVPまたはMVVMを実装する場合、コントローラーのようなコンポーネントには、モデルレイヤーからビューへのデータ転送などの追加の責任がありますが、従来のMVCパターンとModel2 MVCパターンでは、ビューはモデルからのデータを要求するアクティブな構造であると想定されます。層。
JSONの生成に関しては、実際にはビューで発生するはずです。ビューには、すべて（または、テンプレートの使用方法によってはほとんど）のプレゼンテーションロジックが含まれている必要があります。モデルレイヤーから（直接または仲介を通じて）情報を取得し、その情報に基づいて応答を生成する必要があります（複数のテンプレートから作成する場合もあります）。JSONは、応答の単なる異なる形式になります。
2005年にリリースされたRailsフレームワークには、大きな影響があります（そしてほとんどがマイナスです）。本来の目的は、プロトタイピングのフレームワークであり、使い捨てのコードをすばやく作成することでした。これを達成するために、彼らは関心の分離が破られるまでパターンを単純化しました。
彼らは、モデルレイヤーをアクティブなレコード構造のコレクションに置き換えました。これにより、コントローラーでビュー機能を簡単に生成およびマージし、本格的なビューの代わりとして機能するテンプレートを残しました。最初の目標には完璧なソリューションでしたが、他の領域に広がり始めたとき、 「ビューは単なるテンプレート」や「モデルはORM」など、MVCやMVCに触発されたデザインパターンについて多くの誤解が生じました。
コントローラのメソッドは可能な限り薄くする必要があります。つまり、データアクセスはモデル（より具体的にはリポジトリオブジェクト）に属します。
コントローラメソッドをスイッチヤードと考えてください...それらは、実行のためにタスクを他のメソッドに委任することだけを担当します。
コントローラでLinqコードを記述している場合は、サイト構造が変更された場合に変更する必要のある依存関係を作成しており、データアクセスコードを複製している可能性があります。ただし、コントローラーからどこに呼び出しているかに関係なくGetCustomer、モデルにはまだあります。GetCustomerそれは理にかなっていますか？
単にデータにアクセスするよりも広範なビジネスロジックを、モデルの一部と見なされる独自のビジネスロジックレイヤーに配置できます。
JSONについてはよくわかりません。JSONは単なる代替データ表現です。データクラスをJSONに変換できるユーティリティメソッドがある場合はGetCustomer、モデルから呼び出し、コントローラーメソッドでJSONへの変換を実行します。
モデルはデータアクセスを処理する必要があります。
MSDNから：
モデル。モデルオブジェクトは、アプリケーションのデータドメインのロジックを実装するアプリケーションの一部です。多くの場合、モデルオブジェクトはモデルの状態を取得してデータベースに保存します。たとえば、Productオブジェクトは、データベースから情報を取得して操作し、更新された情報をSQLServerデータベースのProductsテーブルに書き戻す場合があります。
MVCでは、モデルがデータアクセスの処理を担当します。長所は、すべてのデータアクセスコードがモデルによって論理的にカプセル化されていることです。コントローラーにデータアクセスコードを含めると、コントローラーが肥大化し、MVCパターンが壊れることになります。