ASP.NET Web Forms vs ASP.NET MVC のバックアップの現在との差分(No.10)

追加された行はこの色です。
削除された行はこの色です。
[[Open棟梁Project>http://opentouryo.osscons.jp/]] - [[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-[[戻る>アプリケーション・アーキテクチャ]]
-戻る
--[[ASP.NET]]
--[[VS系コンテンツ]]
---[[Windows Form vs WPF]]
---ASP.NET Web Forms vs ASP.NET MVC

* 目次 [#r885a125]
#contents

*概要 [#d571e5c0]
-[[ASP.NET Web Forms]]の価値は、
--画面単位のモジュール化と、イベント・ドリブンの実現
--コンポーネントベース、１画面１Formなど、~
フレームワークレベルで実装ルールが決まっているため標準化し易い。
[[ASP.NET Web Forms]] と [[ASP.NET MVC]]のトレードオフをまとめた。

-[[ASP.NET MVC]]の価値は、
--フレームワークレベルでの実装ルールが緩く標準化が困難だが、
--ASP.NETでは意識し難い生HTMLをガリガリ生成＆弄り易い。

と言う事かと思います。

*分析 [#d7fca79d]
*分析結果 [#d7fca79d]
HTML/CSS3/JavaScriptやHTML5が注目される時勢のため、
-[[ASP.NET Web Forms]]が衰退傾向で、
-[[ASP.NET MVC]]が隆盛しつつある。

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

しかし、技術には[[STP>https://ja.wikipedia.org/wiki/STP%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0]]というものがあるので、~
「[[ASP.NET Web Forms]]が衰退して消える。」~
ということはないでしょう。
しかし、歴史的に、

事例として、[[Windows FormsとWPF>Windows Form vs WPF]]を見てみましょう。
-Javaに対するCOBOL
-ホスト、Unix、Linux、[[Windows>Windows OSの設計思想]]
-[[WPFに対するWindows Forms>Windows Form vs WPF]]、VB6.0

>Javaに対するCOBOLや、[[WPF]]に対する[[Windows Forms]]、VB6.0などが良い例です。~
ホスト、Unix、Linux、[[Windows>Windows OSの設計思想]]などもそうだと思います。以下の参考情報も参考になります。
などが良い例だと思いますが、

**ASP.NET Web Forms [#o66a29b3]
エンプラでは、実装レベルで標準化が可能な[[ASP.NET Web Forms]]は、~
以下のように最新のUIテクノロジにも対応し、今後も、まだまだ現役で使い続けられるでしょう。
技術毎に適合する分野が異なるので、

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

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

**[[ASP.NET Web Forms]]の価値 [#j590f622]

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

**[[ASP.NET MVC]]の価値 [#a1774669]

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

>を徹底する必要がある。

*[[ASP.NET Web Forms]] [#o66a29b3]

**[[ASP.NET Web Forms]]の問題 [#x176643a]
[[ASP.NET Web Forms]]の問題は、

***HTML5対応 [#j98ea847]
コンポーネントベースのアプローチを採用しているので~
生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>https://msdn.microsoft.com/ja-jp/library/system.web.ui.webcontrols.webcontrol.aspx]]がHTML5対応されていない。~
--ただし、[[HTML Control>https://msdn.microsoft.com/ja-jp/library/system.web.ui.htmlcontrols.htmlcontrol.aspx]]や[[Repeater>https://msdn.microsoft.com/ja-jp/library/system.web.ui.webcontrols.repeater.aspx]]で代替可能。
--（cHTML、XHTML Mobile Profile対応でも、ほぼ同じ対応が取られていた）。

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

***参考 [#c583c2a8]
-HTML5とHTML4.01 正しいDOCTYPE宣言で仕様に準拠しよう~
https://seopack.jp/internal-seo/basic/html4-html5-doctype.php

-[[HTMLのカスタマイズの難易度が高い>ASP.NET Web Forms#mdd28183]]

-ClientIDMode in ASP.NET 4.0 - Rick Strahl's Web Log~
https://weblog.west-wind.com/posts/2009/nov/07/clientidmode-in-aspnet-40

**大規模開発案件への適応 [#xc2c098f]
エンプラ分野の大規模開発案件では、~
標準化と徹底が容易な[[ASP.NET Web Forms]]は、~

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

-Bootstrap
-jQuery UI
-jQuery(WCF)

などで最新のUIテクノロジにも対応します。
今後も、まだ現役で使い続けられるものと思われる。

**ASP.NET MVC [#ta51d347]
生HTMLをガリガリ生成＆弄り易いため、~
*[[ASP.NET MVC]] [#ta51d347]
生HTMLをガリガリと生成＆弄り易いため、~
「HTML/CSS3/JavaScript」や「HTML5」に~
対応する案件が増える中で、導入数は増えるでしょう。
対応する案件が増える中で、導入数は増えると思われる。

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

-柔軟性は高いが、Formを任意の数だけ定義可能。など、~
実装次第で、標準化の枠から大きくはみ出てしまう。
**高い柔軟性 [#y0a4186b]
柔軟性は高いが、
-1つのViewにFormを任意の数だけ定義可能。
-Controllerと全体Viewの関係が、規約で1対1にならない（n対nにすることもできる）。

-ModelMetadataを使用した表示・編集・検証など、
--ASP.NET MVCの仕様を網羅的に押さえていないと効率的な実装が出来ない。
--ModelMetadataでは実装が分散するので、テンプレートなどで実装を徹底させ難い。
---M（DataAnnotations）
---V（利用するHTMLヘルパー）
---C（ModelState.IsValid）~
など、実装次第で、標準化の枠から大きくはみ出てしまう（枠に収め難い）。

-これらを枠に収めるには、ガイド類（ドキュメント）で徹底するしかない。~
***モジュール構成 [#ffa25144]
-Model、View、Controller

-Mには、
--B層・D層の引数戻り値
--ViewModel

>などが含まれる。

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

***標準化 [#fb970b97]
これらを枠に収めるには、

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

というともあり、エンプラ分野では、[[ASP.NET Web Forms]]を使い続ける案件もあると思います。
**ルールベース [#bb599ba2]
「設定より規約」（CoC:convention over configuration）を重視する[[ASP.NET MVC]]では、~
[[ASP.NET MVC]]の仕様を網羅的に押さえていないと効率的な実装、標準化が出来ない。

-[[ModelMetadata>ASP.NET MVCの利用方法#d39da4a0]]の利用~
表示から検証までの一連の実装が各モジュールに分散するので、テンプレートなどで実装を徹底させ難い。
--M（DataAnnotations）
--V（利用するHTMLヘルパー）
--C（モデルバインディングとバリデーション）~

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

***表示・編集 [#nf773812]
DataAnnotationsと、利用するHTMLヘルパーの関連を理解しておく必要がある。

***モデルバインディング [#y602dd36]
モデルバインディングの仕組みを理解し、name属性の名称を決定する必要がある。
-[[単方向バインディング>ASP.NET MVCの用語#t62a5795]]
-[[双方向バインディング>ASP.NET MVCの用語#i0697eb3]]

***バリデーション [#ldc97ca3]
DataAnnotationsを理解し、標準のバリデーションの機能版囲を理解し、~
必要に応じて[[カスタムのバリデーション>ASP.NET MVCの利用方法#za7f960c]]を実装する必要がある。
-[[CustomValidation属性>ASP.NET MVCの利用方法#f553a183]]
-[[自作Validation属性>ASP.NET MVCの利用方法#l98ac398]]

**大規模開発案件への適応 [#iebe14b1]
エンプラ分野の大規模開発案件で、~
大手SIerが内製しているJavaの自動生成を考える。

-大手SIerが手掛けるエンプラ分野の大規模開発案件では、
>開発言語にJava、Frameworkに柔軟性の高いMVCを採用して、~
Mega Step 規模のユーザ・プログラムを開発している。

-このような案件では、多数の開発者の足並みを揃える事が重要になり、~
[[Excel設計書からのフォワード生成>開発支援ツールの自動生成方式]]のような仕組が必要になるとされている。~
（実際の所、開発要員を多数集めて開発するため、そのような仕組みが必要になる）

-ASP.NET MVCの場合、更にCoCも採用しており、~
開発要員にASP.NET MVCに対する十分な知識が必要になるため、
--自動生成ツールが無い状態での大規模開発は難易度が高いと思われる。
--ただし、自動生成ツールは~
「[[柔軟性に乏しく、多様化の激しい昨今、衰退傾向」>https://www.osscons.jp/joeii3bn2-537/]]なので、~
自動生成メカニズムを新規開発したりせず、~
開発要員に十分な教育を行うと良いと考える。

*参考 [#n6d4da2b]
-「ASP.NET Web Form」か「ASP.NET MVC」か？~
.NETによるWebアプリ開発の今を徹底討論 (1-4)：CodeZine（コードジン）~
http://codezine.jp/article/detail/4367

-Web フォーム vs. MVC~
THE TRUTH IS OUT THERE - Site Home - MSDN Blogs~
-ASP.NET MVCの全体像と、Webフォームとの使い分け － ＠IT~
http://www.atmarkit.co.jp/fdotnet/introwebstandard/introwebstandard02/introwebstandard02_01.html

-Web フォーム vs. MVC - THE TRUTH IS OUT THERE - Site Home - MSDN Blogs~
http://blogs.msdn.com/b/chack/archive/2013/01/16/aspnet-webforms-mvc.aspx

-全盛期を過ぎても生き残り続ける10の開発テクノロジ - ZDNet Japan~
https://japan.zdnet.com/article/35018888/

----
Tags: [[:ASP.NET]], [[:ASP.NET Web Forms]], [[:ASP.NET MVC]]
Tags: [[:.NET開発]], [[:ASP.NET]], [[:ASP.NET Web Forms]], [[:ASP.NET MVC]]