つまり、MVCアプリがあり、別のプロジェクトでは、アプリケーションのビジネスロジックとデータロジックを処理するクラスの通常のコレクションがあります。また、MVCプロジェクト自体のモデルにもいくつかのロジックがあります。このロジックは、ViewModelなどを処理します。これらは、MVCプロジェクト自体に関連しており、同じプロジェクトに存在する必要があるため、n層プロジェクトでは実行できませんでした。
私の質問は次のとおりです。
これが理にかなっていることを願って、私の主張を正しく伝えるのは難しいと感じました。
一般的にここで言えば-モデルクラスにはビジネスロジックの知識があってはなりません。ユーザーにビューを表示するために必要な情報のみが含まれている必要があります（mxmissileによって提案されたDTOを使用してください）。
ビジネスロジックは、コントローラー内にあるか、（より適切に）コントローラーによって呼び出される別のサービスレイヤー内にあります。たとえば、コントローラーをバイパスしてデータベースを直接呼び出すようなメソッドをモデルに設定することは、ほとんどの場合、悪い習慣です。
ここでの考え方は、ビューをできるだけ馬鹿にすることです。あなたは彼らにモデルを送り、彼らは彼らが必要とするデータを引き出し、それを適切にフォーマットし、そしてそれを表示します。これにより、プレゼンテーションを変更する場合に、後で同じデータの新しいビューを作成するのがはるかに簡単になります。
モデルは、コントローラーとビューの間のデータの唯一のコンテナーと考えてください。基本的にDTO。
MVCアプリケーションのViewData/ViewModelクラスには、Modelクラスのインスタンスが含まれている場合があります（私の場合）。私のコントローラーは私のビジネスサービスを呼び出し、ViewDataとModelsの間の変換を担当します。
モデルがn層アプリケーションを参照しても問題がない場合、コントローラーはモデルクラスを介してn層にアクセスする必要がありますか？
モデルを調べてアプリケーション層にたどり着くのではなく、コントローラーをそのインターフェースコンポーネントにします。コントローラは、データアクセスコンポーネントからモデルのインスタンスを返すアプリケーション層を呼び出します。次に、ViewData / ViewModelオブジェクトを使用して、これらのインスタンスをより消費可能なオブジェクトに変換できます。これはコントローラーで行うことも、別のアセンブラークラスを使用することもできます。