マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

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

分析結果

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

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

しかし、歴史的に、

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

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

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

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

ASP.NET Web Formsの価値

ASP.NET Web Formsの価値は、

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

ASP.NET MVCの価値

ASP.NET MVCの価値は、

  • 柔軟性が高く、生HTMLをガリガリ生成&弄り易い。
  • 反面、標準化の枠からはみ出やすい(枠に収め難い)。
  • 以下の様なASP.NET MVCの仕様を網羅的に押さえていないと、標準化~効率的な実装が出来ない。
    • ModelのPropertyや、ActionMethod?へのアノテーションを起点に、実装がMVCの各モジュールに分散する。
    • また、定義も、ModelのPropertyや、ActionMethod?へのアノテーションに分散してしまう。
    • 大規模開発で枠に収めるには、ガイド類(ドキュメント)で、
      • MVCのどの機能を、どう使うか?
      • モジュールかをどのような方針で行うか?

を徹底する必要がある。

ASP.NET Web Forms

ASP.NET Web Formsの問題

ASP.NET Web Formsの問題は、

HTML5対応

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

  • DOCTYPE宣言については書き換え可能。
    • HTML5のDOCTYPE宣言
      <!DOCTYPE html>
    • HTML 4.01のDOCTYPE宣言
      • HTML 4.01厳密型DTD(strict)
        <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
      • HTML 4.01移行型DTD(Transitional)
        <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
      • HTML 4.01 フレーム設定型DTD(Frameset)
        <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">
  • Web ControlがHTML5対応されていない。
    • ただし、HTML ControlRepeaterで代替可能。
    • (cHTML、XHTML Mobile Profile対応でも、ほぼ同じ対応が取られていた)。

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

また、masterページなどを使用している場合、
NamingContainer? IDにより、Name属性や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単位に付与する必要がある。
    • 外部ファイルなどに、属性を集約して定義できない(定義が分散しレビューが難しくなる)。

表示・編集

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

モデルバインディング

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

バリデーション

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

大規模開発案件への適応

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

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

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

  • このような案件では、多数の開発者の足並みを揃える事が重要になり、
    Excel設計書からのフォワード生成のような仕組が必要になるとされている。
    (実際の所、開発要員を多数集めて開発するため、そのような仕組みが必要になる)
  • ASP.NET MVCの場合、更にCoCも採用しており、
    開発要員にASP.NET MVCに対する十分な知識が必要になるため、

参考


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


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2019-02-26 (火) 09:09:20 (208d)