「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
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の問題は、
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">
Name属性やID属性の値の複雑化 †
また、masterページなどを使用している場合、
NamingContainer? IDにより、Name属性やID属性の値が複雑になる。
参考 †
大規模開発案件への適応 †
エンプラ分野の大規模開発案件では、
標準化と徹底が容易なASP.NET Web Formsは、
以下のような最新のUIテクノロジにも対応し、
- Bootstrap
- jQuery UI
- jQuery(WCF)
今後も、まだ現役で使い続けられるものと思われる。
生HTMLをガリガリと生成＆弄り易いため、
「HTML/CSS3/JavaScript」や「HTML5」に
対応する案件が増える中で、導入数は増えると思われる。
しかし、エンプラ分野では、下記のような課題もある。
高い柔軟性 †
柔軟性は高いが、
- 1つのViewにFormを任意の数だけ定義可能。
- Controllerと全体Viewの関係が、規約で1対1にならない（n対nにすることもできる）。
など、実装次第で、標準化の枠から大きくはみ出てしまう（枠に収め難い）。
モジュール構成 †
などが含まれる。
これらのモジュール構成の検討が難しい。
標準化 †
これらを枠に収めるには、
ガイド類（ドキュメント）「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
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
