Skip to content

MS_ASPNETWebFormsVsMVC

Jump to bottom
nishi_74322014 edited this page Aug 12, 2026 · 1 revision

ASP.NET Web Forms vs ASP.NET MVC

概要

ASP.NET Web Forms と ASP.NET MVCの
トレードオフをまとめた。

分析結果

HTML/CSS3/JavaScript や HTML5 が注目される時勢のため、

というのが世間一般の認識だと思います。

しかし、歴史的に、

などが良い例だと思いますが、

技術毎に適合する分野が異なるので、

「単純に古いからASP.NET Web Formsが衰退して消える。」

ということは無いと思います。

ASP.NET Web Formsの価値

  • 画面単位のモジュール化、コンポーネントベース、イベント・ドリブンの実現
  • １画面１Form などフレームワークレベルで実装ルールが決まっているため
    標準化し易い。

ASP.NET MVCの価値

  • 柔軟性が高く、生 HTML をガリガリ生成＆弄り易い。

  • 反面、標準化の枠からはみ出やすい（枠に収め難い）。

  • 以下の様なASP.NET MVCの仕様を網羅的に押さえていないと、
    標準化〜効率的な実装が出来ない。

    • Model の Property や、ActionMethod へのアノテーションを起点に、
      実装が MVC の各モジュールに分散する。
    • また、定義も、Model の Property や、ActionMethod へのアノテーションに
      分散してしまう。
    • 大規模開発で枠に収めるには、ガイド類（ドキュメント）で、
      • MVC のどの機能を、どう使うか？
      • モジュール化をどのような方針で行うか？

    を徹底する必要がある。

補足（この対立は決着した）: 本ページの「単純に消えることは無い」という
見立ては、当時としては妥当であり、実際 ASP.NET Web Formsは
長く現役だった。ただし、その後の展開は次のとおりである。

現在
ASP.NET Web Forms .NET Core 以降に移植されなかった。.NET Framework 上でのみ動作し、新機能は無い
ASP.NET MVC (MVC5) 同上。後継は ASP.NET Core MVC
後継 ASP.NET Core MVC / Razor Pages / Blazor

つまり「Web Forms が MVC に負けた」のではなく、
両方が .NET Framework と共に据え置きになったというのが正確である。

なお、Web Forms の「コンポーネント ベース・イベント ドリブンで
標準化しやすい」という価値そのものは失われておらず、
Blazor がその路線を引き継いでいる
（コンポーネント単位・イベント ハンドラ・状態はサーバー側）。
Web Forms 経験者が Blazor に馴染みやすいのはこのためである。

ASP.NET Web Forms

ASP.NET Web Formsの問題

HTML5対応

コンポーネントベースのアプローチを採用しているので
生 HTML をガリガリと生成＆弄り難いことである。

  • DOCTYPE 宣言については書き換え可能。

    • HTML5 の DOCTYPE 宣言

      <!DOCTYPE html>

    • HTML 4.01 の DOCTYPE 宣言（厳密型 / 移行型 / フレーム設定型）

      <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

  • Web Control が HTML5 対応されていない。

    • ただし、HTML Control や Repeater で代替可能。
    • （cHTML、XHTML Mobile Profile 対応でも、ほぼ同じ対応が取られていた）。

Name属性やID属性の値の複雑化

また、master ページなどを使用している場合、
NamingContainer ID により、Name 属性や ID 属性の値が複雑になる。

補足: この問題は .NET Framework 4 の
ClientIDMode で緩和された。

値 挙動
AutoID 従来どおり ctl00_MainContent_txtName のような ID が付く
Static 指定した ID がそのまま出力される（JavaScript / CSS から扱いやすい）
Predictable 規則的に生成（データ バインド コントロール向け）
Inherit 親に従う（既定）

Web.config で既定を Static にしてしまう手もあるが、
ID の重複を自分で管理する責任が生じる点には注意が要る。

参考

大規模開発案件への適応

エンプラ分野の大規模開発案件では、
標準化と徹底が容易なASP.NET Web Formsは、

以下のような最新の UI テクノロジにも対応し、

  • Bootstrap
  • jQuery UI
  • jQuery（WCF）

今後も、まだ現役で使い続けられるものと思われる。

ASP.NET MVC

生 HTML をガリガリと生成＆弄り易いため、
「HTML/CSS3/JavaScript」や「HTML5」に
対応する案件が増える中で、導入数は増えると思われる。

しかし、エンプラ分野では、下記のような課題もある。

高い柔軟性

柔軟性は高いが、

  • 1 つの View に Form を任意の数だけ定義可能。
  • Controller と全体 View の関係が、規約で 1 対 1 にならない
    （n 対 n にすることもできる）。

など、実装次第で、標準化の枠から大きくはみ出てしまう（枠に収め難い）。

モジュール構成

  • Model、View、Controller

  • M には、

    • B層・D層の引数戻り値
    • ViewModel

    などが含まれる。

これらのモジュール構成の検討が難しい。

標準化

これらを枠に収めるには、

ガイド類（ドキュメント）「MVC のどの機能を、どう使うか？」を
徹底するしかない。
従って、ガイド類（ドキュメント）が十分で無いと、
大規模開発などで問題が発生しやすい。

ルールベース

「設定より規約」（CoC: convention over configuration）を重視する
ASP.NET MVCでは、
ASP.NET MVCの仕様を網羅的に押さえていないと
効率的な実装、標準化が出来ない。

  • ModelMetadata の利用
    表示から検証までの一連の実装が各モジュールに分散するので、
    テンプレートなどで実装を徹底させ難い。

    • M（DataAnnotations）
    • V（利用する HTML ヘルパー）
    • C（モデルバインディングとバリデーション）

  • フィルタ属性やセレクタ属性の利用
    属性は Action Method 単位に分散して定義する。集約して定義できない。

    • フィルタ属性やセレクタ属性は Action Method 単位に付与する必要がある。
    • 外部ファイルなどに、属性を集約して定義できない
      （定義が分散しレビューが難しくなる）。

移行メモ（補足）: 「属性を集約して定義できない」という指摘は
グローバル フィルタ（GlobalFilters.Filters.Add()、
ASP.NET Coreでは MvcOptions.Filters.Add()）で
一部緩和できる。
「全 Action に認証を効かせる」といった横断的関心事は
こちらで一括指定するのが定石である。
ただし「特定の Action だけ属性で個別指定」という部分は
依然として分散するため、本ページの指摘自体は今も有効である。

表示・編集

DataAnnotations と、利用する HTML ヘルパーの関連を理解しておく必要がある。

モデルバインディング

モデルバインディングの仕組みを理解し、
name 属性の名称を決定する必要がある。

  • 単方向バインディング（ASP.NET MVCの用語（MS_ASPNETMVCTerms.md））
  • 双方向バインディング（同上）

バリデーション

DataAnnotations を理解し、標準のバリデーションの機能範囲を理解し、
必要に応じてカスタムのバリデーションを実装する必要がある。

  • CustomValidation 属性
  • 自作 Validation 属性

移行メモ（誤字）: 元ページの「機能版囲」は「機能範囲」の誤記である。

大規模開発案件への適応

エンプラ分野の大規模開発案件で、
大手 SIer が内製している Java の自動生成を考える。

  • 大手 SIer が手掛けるエンプラ分野の大規模開発案件では、

    開発言語に Java、Framework に柔軟性の高い MVC を採用して、
    Mega Step 規模のユーザ・プログラムを開発している。

  • このような案件では、多数の開発者の足並みを揃える事が重要になり、
    Excel 設計書からのフォワード生成（MS_DevSupportToolCodeGen.md）のような
    仕組が必要になるとされている。
    （実際の所、開発要員を多数集めて開発するため、
    そのような仕組みが必要になる）

  • ASP.NET MVCの場合、更に CoC も採用しており、
    開発要員に ASP.NET MVC に対する十分な知識が必要になるため、

    • 自動生成ツールが無い状態での大規模開発は難易度が高いと思われる。
    • ただし、自動生成ツールは
      「柔軟性に乏しく、多様化の激しい昨今、衰退傾向」なので、
      自動生成メカニズムを新規開発したりせず、
      開発要員に十分な教育を行うと良いと考える。

補足（現在の観点）: 「自動生成に頼らず教育する」という結論は
現在でも妥当だが、そこに至る前提は変わっている。

  • CoC の学習コストは、ASP.NET Coreで
    さらに上がった（DI・ミドルウェア・タグ ヘルパー・Razor Pages）。
  • 一方、IDE と AI 補完（Copilot 等）が
    定型コードの生成を肩代わりするようになり、
    「Excel 設計書からのフォワード生成」という重い仕組みを
    自前で持つ必然性は下がった。
  • 標準化の手段も、ドキュメントの徹底から
    アナライザー / EditorConfig / テンプレート プロジェクトという
    「機械が強制する」方向へ移っている。

「規約は人ではなくツールに守らせる」という点が、
本ページ執筆時からの最大の変化である。

参考

Tags: 移行, .NET開発, ASP.NET, ASP.NET Web Forms, ASP.NET MVC

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally