私が働いているところには、.NET3.5でwebformsプロジェクトとして書かれたプロジェクトがあります。階層化されています。プレゼンテーション層、ロジック層、および後でデータ。
これらの毎週の「技術セッション」が機能しています。MVCについてプレゼンテーションを行いました。
私の技術リーダーは割り込むことにし、上記のプロジェクト（階層型、Webフォーム）はMVCと同じであると教えてくれました。彼は続けて次のことを説明しました。
簡単に言えば、上記のプロジェクト（階層型Webフォーム）がMVCを構成するかどうかについて、私たちは未解決の議論に巻き込まれました。
誰かがこの議論を提供して答えることができますか？
ありがとう
番号。mvcは、主に関心の分離を強力に行うために使用されます。コントローラとビューは相互に関連付けられておらず、モデルの受け渡し（または受け渡しなし）以外に他の知識を持っていません。単一のコントローラーを使用して多くのビューをレンダリングできますが、背後にあるaspxコードは、すべて同じ部分クラスの一部であるため、単一のaspxページに強く関連付けられています。ほとんどのMVCアプリケーションでは、モデルは実際のドメインデータ型ではなく、ビューのレンダリングに使用できるいくつかのコンポジットであると言う以外は、モデルの違いは少なくなります。
mvcと異なるもう1つの点は、厳密な階層フォルダー構造と命名規則です。これにより、ベストプラクティスが促進され、関心の分離が促進されます。
マイクロソフトがasp.netmvcフレームワークを作成したのには理由があり、ルーティングなどを使用してWebフォームでmvcの感触をエミュレートできる場合もありますが、まったく同じではありません。
また、これはasp.net mvcに向かって傾斜していますが、他にも多くのフレアが存在することは明らかです。FubuMVCもチェックすることをお勧めします。
率直に言って、技術リーダーは間違っています。
これまで真のMVCフレームワークを使用したことがない人には、「MVC」はWebフォームの単なる異なるフレーバーであるという一般的な誤解がありますが、実際には、真実から遠く離れることはできません。
これが当てはまる理由を理解するには、アーキテクチャパターンであるMVCと、 MVCパターンを実装するMicrosoftによって構築されたフレームワークであるASP.NETMVCの違いを理解する必要があります。
多くの場合、このトピックを完全に理解していない技術リーダーやアーキテクトなどの人々は、「MVC」という用語を使用して、パターンとフレームワークの違いを理解せずにパターンとフレームワークの両方を説明します。これはしばしば混乱を招きます。
したがって、明確にするために、MVCパターンは新しいものではなく、実際には次のような多くのフレームワークによって実装されています。
Webformsは、MVCパターンをすぐに実装するフレームワークの1つではありません。
これで、 WebFormsにMVCパターンを実装できることは事実ですが、WebformsはMVPスタイルのパターンを実装するのに適しています。実際、この点で役立つフレームワーク（このような）があります。
ただし、技術リーダーが何について話しているのかわからないことを示す最大の指標は次のとおりです。
私の技術リーダーは割り込むことにしました。上記のプロジェクト（階層型、Webフォーム）はMVCと同じであると教えてください
アプリケーションに「層」を導入することは、MVCとは何の関係もありません。実際、階層型アーキテクチャ内では、MVCアプリケーションは完全にプレゼンテーション層内にあり、他のアプリケーション層とは何の関係もありません。
フロントエンドにASP.NETMVCを使用するということは、ASP.NETMVCフレームワークを使用して実装されたロジックレイヤーの上にプレゼンテーション層があることを意味します。MVCを使用しているという理由だけで、他の層の必要性が突然なくなったという意味ではありません。
逆に、Webformsは、階層型アーキテクチャ内の単なるプレゼンテーション層です。階層型アーキテクチャを使用しているからといって、MVCパターンを使用していることを意味するわけではありません。
他の各ポイントへ：
ビューは単なるASPXページ ですこれは真実ではありません。ASPXページは非常に複雑な獣であり、MVCビュー間に非常に大きな違いが1つあります。
それらは状態を維持するように設計されています
ページライフサイクルとビューステートのこのシステム全体と、ポストバック間の状態を維持するように設計されたコントロールがあります。
ASP.NET MVCはステートレスになるように設計されているため、ビューにはそのような複雑さは含まれていません。
コントローラーはページの後ろにあります
このステートメントは、コントローラーの要点を完全に見逃しています。
コードビハインドは、ASPXページのレンダリングプロセスに関係するすべてのものを明示的に認識しています。これは、ページのコントロール、ページの状態、ページのライフサイクルを認識しており、ビューと非常に緊密に結合されています。
コードビハインドも1つだけを返します。aspxページ。
コントローラははるかに柔軟性があり、ビューを返すだけでなく、データのさまざまな表現をレンダリングするためのロジックを制御するために使用できます。たとえば、同じデータを標準のhttpリクエストの場合はHTMLとしてレンダリングしたり、AJAXリクエストの場合はJSONとしてレンダリングしたりできます。
これが可能なのは、コントローラーロジックとビューロジックが緩く結合されているためです。
モデルは単なるデータオブジェクトです
これは間違っています。データオブジェクトをビューに直接バインドすることは、あらゆる種類の複雑さを持つあらゆる種類のMVCアプリケーションではまれです。簡単に言えば、データベースでデータをモデル化する方法が、ビューの表示に必要なデータを表すことはめったにありません。
たとえば、「TitleId」を持つ従業員レコードがあるとします。レコード内のデータは単なるintですが、意味をなすためには、実際のテキスト値をユーザーに表示する必要があります。
したがって、ほとんどのMVCアプリケーションでは、「モデル」は実際には「ViewModel」としてより正確に記述され、データまたはドメインモデルから完全に分離されています。
要約すると
あなたの技術リーダーは間違っており、セマンティックレベルだけでなく、「あなたが話していることについてのアイデアがない」レベルでも間違っています。
お役に立てば幸いです。
パターンとして、MVCは特定のテクノロジ（WebForms、WinForms、ASP.NET MVCなど）に依存しません。
したがって、WebFormsで実際にMVCを実行することは非常に可能です。
CodeBehindファイルはコントローラーとして扱うことができますが、技術的には正しくありません。コードビハインドファイルとaspxファイルは両方とも（部分的なクラスであるため）1つのタイプにコンパイルされるため、この問題にはコントローラータイプとビュータイプはありません;）しかしこの違いはマイナーなものと見なすことができます。
WebFormsは、MVCパターンを実装するものと見なすことができ、非常に醜い実装であり、非常に簡単に混乱する可能性があることを認めています。しかし、（通常発生するように）混乱すると、少なくともViewとControllerの間の分離の懸念の全体的な考え方に違反するため、この分離がぼやけたり消えたりすると、MVCではなくなったと言えます。
履歴書：WebFormsはMVCパターンの実装として扱うことができますが、この実装でこのパターンに従うのは非常に難しいため、MVCのままになることはめったになく、その概念の範囲内にとどまります。