ASP.net MVCの主な利点は次のとおりです。
レンダリングされたHTMLのフルコントロールを有効にします。
懸念事項の明確な分離（SoC）を提供します。
テスト駆動開発（TDD） を有効にします。
JavaScriptフレームワークとの簡単な統合。
Webのステートレスな性質の設計に従う。
SEOを有効にするRESTful URL。
ViewStateおよびPostBackイベントはありません
ASP.net Web Formの主な利点は次のとおりです。
RAD 開発を提供します
Winform開発から来た開発者向けの簡単な開発モデル。
ASP.NET WebフォームとMVCは、マイクロソフトが開発した2つのWebフレームワークです。どちらも適切な選択肢です。 Webフレームワークのいずれかを他方に置き換えることも、単一のフレームワークに「マージ」する計画もありません。継続的なサポートと開発は、Microsoftによって並行して行われ、どちらも「なくなる」ことはありません。
これらのWebフレームワークにはそれぞれ長所/短所があり、Webアプリケーションを開発する際にはその一部を考慮する必要があります。 Webアプリケーションは、どちらのテクノロジーを使用しても開発できます。特定のアプリケーションの開発では、一方のテクノロジーと他方のテクノロジーの選択が容易になります。
ASP.NET Webフォーム：
- 開発は状態をサポートします•Windowsアプリケーションと同様に、Webアプリケーションがユーザーが何をしていたかを認識しているような錯覚を与えます。つまり「ウィザード」機能を実装しやすくします。 Webフォームは、その複雑さの多くを開発者から隠すのに非常に役立ちます。
- Rapid Application Development（RAD）•「ジャンプ」してWebフォームの配信を開始する機能。これは、一部のMVCコミュニティによって異議が唱えられていますが、Microsoftによって推進されています。最終的には、開発者の専門知識のレベルと彼らが満足しているものに帰着します。 Webフォームモデルは、おそらく、経験の少ない開発者にとって学習曲線があまりありません。
- 大規模なコントロールツールボックス•ASP.NET Webフォームは、はるかに強力で堅牢なツールボックス（Webコントロール）を提供しますが、MVCは、jQuery（Javascript）を介したリッチクライアント側のコントロールに依存するより原始的なコントロールセットを提供します。
- 成熟•2002年以降、質問や問題などに関する情報が豊富にあります。より多くのサードパーティ製コントロールを提供します。既存のツールキットを検討する必要があります。
ASP.NET MVC：
- 懸念の分離（SoC）•技術的な観点から、MVC内のコードの編成は非常にクリーンで、組織化され、きめ細かく、Webアプリケーションの機能面でのスケーリングを（できれば）容易にします。開発の観点から素晴らしいデザインを促進します。
- クライアントサイドツール（リッチユーザーインターフェイスツール）との統合が容易になります•Webアプリケーションは、デスクトップに表示されるアプリケーションと同様に、ますますリッチになっています。 MVCを使用すると、このようなツールキット（jQueryなど）との統合が可能になり、Webフォームよりも簡単かつシームレスになります。
- 検索エンジン最適化（SEO）フレンドリー/ステートレス•URLは検索エンジンにより使いやすい（つまり、mywebapplication.com/users/1-IDが1のユーザーとmywebapplication/users/getuser.aspx（セッションで渡されたID））。同様に、MVCはステートレスであるため、これにより、同じウィンドウから複数のWebブラウザーを生成するユーザーの頭痛がなくなります（セッションの衝突）。それらと同じ線に沿って、MVCは、それに対して「戦う」のではなく、ステートレスWebプロトコルに準拠します。
- 高度な制御が必要な開発者との連携•ASP.NET Webフォームの多くのコントロールは、ページのレンダリング時に表示される生のHTMLの多くを自動的に生成します。これは開発者に頭痛の種を引き起こす可能性があります。 MVCを使用すると、レンダリングされるものを完全に制御できるようになり、驚くことはありません。さらに重要なことは、HTMLフォームは通常、パフォーマンスの向上に相当するWebフォームよりもはるかに小さいことです。
- テスト駆動開発（TDD）•MVCを使用すると、物事のWebサイドのテストをより簡単に作成できます。テストの追加レイヤーは、予期しない動作に対する防御のさらに別のレイヤーを提供します。
認証、承認、構成、コンパイル、およびデプロイメントはすべて、2つのWebフレームワーク間でsharedである機能です。
古典的なASPを覚えるのに十分な年齢の人なら、htmlとjavascriptを混ぜたコードでページを開くという悪夢を覚えているでしょう。私は間違っている可能性があり、私はそうであることを願っていますが、MVCはそれらの悪い昔に戻るように見えます。
ASP.Netが登場したとき、コンテンツからコードを分離し、WebデザイナーにHTMLを作成させ、コーダーがコードビハインドで作業できるようにすることで、救世主として歓迎されました。 ViewStateを使用したくない場合は、オフにしました。何らかの理由でコードビハインドを使用したくない場合は、古典的なASPのようにHTML内にコードを配置できます。 PostBackを使用したくない場合は、処理のために別のページにリダイレクトしました。 ASP.Netコントロールを使用したくない場合は、標準のHTMLコントロールを使用しました。コントロールでASP.Net runat = "server"を使用したくない場合は、Responseオブジェクトに問い合わせることもできます。
今、偉大な知恵のある人（おそらく古典的なASPをプログラミングしたことのない人）は、コードをコンテンツと混在させる時代に戻って、「懸念の分離」と呼ぶことにしました。確かに、よりクリーンなhtmlを作成できますが、従来のASPで作成できます。 「ビュー内にコードが多すぎると正しくプログラミングされていません」と言うことは、「古典的なASPで適切に構造化されコメントされたコードを書いた場合、ASP.NETよりもずっときれいで優れている」と言うようなものです
コードをコンテンツと混合することに戻りたい場合は、PHPを使用した開発を検討します。このような開発には、はるかに成熟した環境があります。 ASP.NETに非常に多くの問題がある場合、それらの問題を修正してみませんか？
最後になりましたが、新しいRazorエンジンは、htmlとコードを区別するのがさらに難しいことを意味します。少なくとも、開始タグと終了タグ、つまりASPの<％と％>を探すことができましたが、現在は@記号のみが表示されます。
PHPに移行し、誰かが再びコンテンツからコードを分離するまでさらに10年待つ時間になるかもしれません。
PHPやJSPなど、他の開発者と作業している場合（そしてRailsを推測している場合）、これらすべてを持っていないため、ページでの変換やコラボレーションがはるかに簡単になります。どこでも「厄介な」ASP.NETイベントとコントロール。
MVCの問題は、「専門家」にとっても貴重な時間を大量に消費し、多くの労力を必要とすることです。ビジネスは、その背後にあるテクノロジーに関係なく、基本的な「機能するクイックソリューション」によって推進されます。 WebFormsは、時間とお金を節約するRADテクノロジーです。より多くの時間を必要とするものはすべて、企業では受け入れられません。
- 適切なAJAX、例JSONResultsは部分的なページポストバックナンセンスを返しません。
- ビューステート+1なし
- HTML IDの名前変更はありません。
- きれいなHTML =肥大化せず、XHTMLまたは標準に準拠したページのレンダリングで適切なショットを持っています。
- 生成されたAXD JavaScriptはありません。
ASP.Netを上回るMVCの利点を見たことはありません。 10年前、MicrosoftはMVCの答えとしてUIP（ユーザーインターフェイスプロセス）を考案しました。フロップでした。当時、私たちはUIPで大規模なプロジェクト（開発者4人、デザイナー2人、テスター1人）を行いましたが、それはまったくの悪夢でした。
誇大広告のために時流に飛び乗らないでください。上記のすべての利点は、Asp.Netで既に利用可能です（Asp.Net 4のより優れた調整[ Asp.Net 4の新機能 ]）。
開発チームまたはAsp.Netを使用する単一の開発者ファミリに固執し、美しい製品を迅速に作成して、クライアント（勤務時間の支払いをする人）を満足させる場合。 MVCは貴重な時間を浪費し、Asp.Netと同じ結果を生成します:-)
私にとって最大の利点は、モデル、ビュー、コントローラーの各レイヤーを明確に分離できることです。それは最初から良いデザインを促進するのに役立ちます。
フランシス・シャナハン、
部分的なポストバックを「ナンセンス」と呼ぶのはなぜですか？これはAjaxのコア機能であり、AtlasフレームワークおよびTelerikのような素晴らしいサードパーティコントロールで非常によく利用されています。
ビューステートに関するあなたの意見に同意します。ただし、開発者がビューステートを無効にすることに注意すると、レンダリングされるHTMLのサイズを大幅に削減できるため、ページが軽量になります。
ASP.NET WebフォームモデルではHTMLサーバーコントロールのみが名前変更され、純粋なhtmlコントロールでは名前が変更されません。それが何であれ、名前の変更が行われたらどうしてそんなに心配するのですか？クライアント側で多くのjavascriptイベントに対処したいのですが、Webページをスマートに設計すれば、必要なすべてのIDを確実に取得できます
ASP.NET Web FormsでさえXHTML標準に適合しており、膨満感はありません。これは、MVCパターンが必要な理由の正当化ではありません
繰り返しますが、なぜAXD Javascriptに悩まされているのですか？なぜあなたを傷つけるのですか？これは再び正当な理由ではありません
これまでのところ、私は古典的なASP.NET Webフォームを使用してアプリケーションを開発するのが好きです。例：ドロップダウンリストまたはグリッドビューをバインドする場合、最大で30分、20行以下のコードが必要です（もちろん最小限）。しかし、MVCの場合は、開発者にそれがどれほど苦痛かを話してください。
MVCの最大の欠点は、ASPの時代に戻っていることです。サーバーコードとHTMLを組み合わせたスパゲッティコードを覚えていますか？ああ、なんと、javascript、HTML、JQuery、CSS、Serverタグなどが混在するMVC aspxページを読んでみてください。
Webフォームは、成熟度の向上とTelerikなどのサードパーティの制御プロバイダーからのサポートからも得られます。
Webフォームでは、PageAdaptersで削除できるviewstate、eventvalidationなどのいくつかのタグを除き、ほとんどすべてのhtmlを手でレンダリングすることもできます。 GridViewや、不適切なHTMLレンダリング出力を持つ他のサーバー側コントロールを強制的に使用することはありません。
MVCの最大の利点は速度です！
次は、懸念の分離です。しかし、コントローラーおよびアクション内にBLおよびDALロジック全体を配置することを禁止しません！これは単にビューの分離であり、Webフォーム（たとえば、MVPパターン）でも実行できます。人々がmvcについて言及していることの多くは、Webフォームで行うことができますが、多少の努力が必要です。
主な違いは、リクエストはビューではなくコントローラーに送られ、これらの2つのレイヤーは分離され、Webフォームのような部分クラスを介して接続されないことです（aspx +コードビハインド）
私の2セント：
- ASP.netフォームは、迅速なアプリケーション開発とビジネス価値の迅速な追加に最適です。私は今でもほとんどのイントラネットアプリケーションで使用しています。
- MVCは、URLとHTMLを大幅に制御するため、検索エンジン最適化に最適です
- MVCは通常、はるかに無駄のないページを生成します。ビューステートがなく、HTMLがすっきりしています=読み込み時間が短い
- ページの一部をキャッシュしやすいMVC。 -MVCは書くのが楽しいです：-個人的な意見;-)
MVCでは、1ページに複数のフォームを配置できます。小さな機能ですが、便利です。
また、私が感じているMVCパターンは、特にコードの保守を容易にします。数か月後に再訪したとき。
MVCコントローラー：
[HttpGet]
public ActionResult DetailList(ImportDetailSearchModel model)
{
Data.ImportDataAccess ida = new Data.ImportDataAccess();
List<Data.ImportDetailData> data = ida.GetImportDetails(model.FileId, model.FailuresOnly);
return PartialView("ImportSummaryDetailPartial", data);
}
MVCビュー：
<table class="sortable">
<thead>
<tr><th>Unique Id</th><th class="left">Error Type</th><th class="left">Field</th><th class="left">Message</th><th class="left">State</th></tr>
</thead>
<tbody>
@foreach (Data.ImportDetailData detail in Model)
{
<tr><th>@detail.UniqueID</th><th class="left">@detail.ErrorType</th><th class="left">@detail.FieldName</th><th class="left">@detail.Message</th><th class="left">@detail.ItemState</th></tr>
}
</tbody></table>
それはどれくらい難しいですか？ ViewStateなし、BSページライフサイクルなし...純粋に効率的なコード。
私が見つける主な利点は、プロジェクトをよりテスト可能な構造に強制することです。これはWebフォームでも非常に簡単に実行できますが（MVPパターン）、開発者はこれを理解する必要がありますが、多くはそうではありません。
WebformとMVCはどちらも実行可能なツールであり、どちらもExcelは異なる領域にあります。
私は主にB2B/LOBアプリを開発するため、個人的にWebフォームを使用しています。しかし、ユニットテストでは95％以上のコードカバレッジを達成できるMVPパターンで常にそれを行います。これにより、webcontrolsプロパティのプロパティのテストを自動化することができます。
bool IMyView.IsAdminSectionVisible{
get{return pnlAdmin.Visible;}
get{pnlAdmin.Visible=value;}
}
）このレベルのテストは、モデルを汚染することなく、MVCで簡単に達成できるとは思いません。
小規模なサイトの利点は2つだけです。6）SEOを有効にするRESTful URL。 7）ViewStateおよびPostBackイベントはありません（および一般的にパフォーマンスが向上します）
小規模なサイトのテストは問題ではありません。サイトがとにかく適切にコーディングされていれば、設計上の利点もありません。MVCは多くの点で難読化され、変更が難しくなります。これらの利点がそれだけの価値があるかどうかはまだ判断しています。
大規模な複数の開発者のサイトでMVCの利点をはっきりと見ることができます。
個人的な意見では、ASP.Net MVCを使用する最大の欠点は、CODE BLOCKSとHTMLが混在していることです...
html地獄それを維持する開発者のための...
最新のjavascriptコントロールとJSONリクエストは、MVCを使用して非常に簡単に処理できます。そこでは、他の多くのメカニズムを使用して、あるアクションから別のアクションにデータをポストできます。 WebフォームよりもMVCを好むのはそのためです。また、軽量のページを作成できます。