私にはサービスレイヤーがあり、メソッドをMVCの「レイヤー」に公開しています。私が次のような方法を持っているとしましょう：
Public List<StateObjects> GetStates()
モデルオブジェクトのコンストラクターからそのメソッドを呼び出して、ビューの状態のSelectListを作成するのは、良い設計ですか、それとも悪い設計ですか。モデルにサービスレイヤーへの参照を含める必要がありますか？また、コントローラーにサービスレイヤーへの参照を許可する必要がありますか？または、モデルの変数の入力をコントローラーで行う必要があるので、すべてのロジックをコントローラーに含める必要がありますか？
アプリケーションのサイズと範囲によっては、明確な答えではないかもしれませんが、サービスレイヤーと組み合わせると、MVCの「M」をビューモデルに近づける傾向があります。
MVVMと同様に、モデルは、ビューに表示されるプロパティのみを含むフラットオブジェクトになります。コントローラはサービスレイヤーにアクセスし、AutoMapperを使用してドメインオブジェクトのプロパティをモデルにマップします。
最終的にはシンコントローラーとシンモデルになり、ほとんどのロジックはサービスレイヤーに残ります。モデルに実際にロジックがあるのは、リスト（StateObjectsのリストなど）をSelectListsにマッピングするか、他のビュー関連の関数/計算を行う場合のみです。また、モデルは比較的フラットであるため、任意のタイプの非同期JavaScript開発を行っている場合は、モデルをJSONオブジェクトに簡単にマップできます。
モデルがサービスレイヤーを直接参照するということは、ある種の依存性注入を使用しようとする場合、すべてのサービスをコンストラクターに渡す必要があることを意味します。これにより、モデルのインスタンス化が非常に困難になる可能性があります。
それがMVCパラダイムを破るかどうかはわかりませんが、過去に行ったプロジェクトではうまく機能しました。
答えは次のとおりです。
アプリケーションとコーディングスタイルによって異なります。
多くの人がリーンモデルとファットコントローラーを練習していますが、オブジェクト指向の背景が重いため、ファットモデルとリーンコントローラーを使用する方が自然な感じがします。これが私がそれをどう思うかです：
モデルはそれ自体について知っている必要があります。これは、モデルに依存する関数がモデルに属することを意味します。
モデルは他のモデルに依存しない必要があります。コントローラーは、モデル間の相互作用（およびインスタンスのみを含まないその他の相互作用）を処理する必要があります。
そうすれば、エレガントinstance.function()でcontroller.staticLikeFunction()。
IMOこれは、オブジェクト指向のアプリケーションを使用している場合に最も美しい方法です。
アプリケーションがオブジェクト指向の設計を必要としない場合、意味がありません。その場合は、すべてをコントローラーに投入し、モデルを純粋にデータとして保持します。
ご指摘のとおり、2つの実際のオプションがあります。
3番目のオプションもあります。これは、ドメインレイヤーにMVCのMC部分を含めることです。これにより、モデルの作成が容易になりますが、ビジネスレイヤーの機能との境界線が少し曖昧になります（純粋主義者の場合）。実際には、巨大なエンタープライズモデルを構築するまでは重要ではありません。
私の特定の好みは静的にすることです
public static MyModel FromDomainObject(DomainObject object)
モデルのメソッド。次に、これをコントローラーで使用し、アクションでドメインオブジェクトを渡してモデルを取得し、それをビューに渡すことができます。
重要なのは、モデルのプロパティがオンデマンドで入力されないようにすることと、ビューからメソッドにアクセスできないようにすることです。実際には、あなたまたはチームはこれらのメソッド/プロパティを呼び出し、その影響を認識しますが、関心の分離を維持し、結合を減らすのに役立ちます。
モデルとしてビューモデルを使用し、無駄を省いたほうがよいでしょう。ビューとコントローラーと通信するのに十分な情報のみが含まれている必要があり、それ以上は含まれていません。
コントローラに必要な他のロジックは、クラス内に含めることができ、コントローラによってインスタンス化できます。これにより、ロジックが緩く結合されたままになるため、保守が容易になります。あなたは自分に恩恵を与えるでしょう。