更新履歴

初めに

 ASP.NET を利用して Web アプリケーションを作成するための入門用ホームページです。 ASP.NET を利用した　Web アプリケーションは古くは Web Form と呼ばれる形式で作られていました。 その後、 MVC と呼ばれるフレームワークが提供されるようになりました。現在では、その MVC フレームワークにもさまざまなヴァージョンが登場しています。
 ここでは、やや古いかもしれませんが Web Form vs MVC 5 を比較しながら、ほぼ同じ動作する Web アプリケーションをサンプルとしています。なるべく、個別の知識の集積ではなくより設計よりの内容にしたいと考えています。

 今回の Web アプリケーションで使用している開発技術は Web Form と MVC に共通で以下のものを使用しています。

• 開発用パソコンの OS は、 Windows 10 Pro 64 ビットと Windows 7 Pro 64 ビットを使用しました
• 開発環境には Visual Studio 2017 Community を使用し、開発言語には C# 4.6 を使用しました
• データベースサーバとしては SQL Server 2014 Express を使用しました
  Web Form と MVC とデータベースは全く同じものを使用しています
• クライアント用のプログラミングには、 jQuery v3.1 を使用しました
  クライアント用プログラム言語に javascript を直接使用することはしません。javascript ライブラリの jQuery を使用します
• クライアント用の画面構築フレームワークには、 bootstrap v3.3 を使用しました
• 地図データの操作には、 Google Map API を使用しました
• 動作確認用のブラウザには、 Google Chrome を使用しました
• より柔軟な操作性を実現するために、Ajax や Web サービスを使用しています

 ２つの違いとしては、ほぼ　ASP.NET 単独で構築しているか、 MVC 5 のフレームワークを使用しているかのみといってよいです。

開発の経緯

 私の住んでいるところに、外来の動植物の排除に取り組んでいるグループがあります。その活動により、さまざまな野外調査のデータが集まってくるのですが、 そのデータを一元管理するといったことは行っていませんでした。そこで、ボランティアとしてソフトウェアを作ってあげようというのが、作成の動機になります。

 ここで話題にしているアプリケーションは、最初に Windows WPF として作成しました。その後、より有用性が増すと思い、 Web アプリケーションの Web Form として作成しました。 ASP.NET を利用した Web アプリケーション作成の知識・経験はすでにあったため、より簡単に作成できると考えたからです。 Web アプリケーションとして一通り完成した後に、今度は MVC の知識を習得するためにアプリケーションを書き換えました。

 そのため２つの Web アプリケーションはほとんど同じ環境で作成・動作させることになりました。特に、Web Form で当初作成した地図表示用の各種プログラムは、 MVC でもそのまま流用しました。 さらに、 Web アプリケーションとして必要な Web サービスプログラムも、そのまま流用してあります。 Web Form と MVC での画面の構成や画面遷移といった点も、可能な限り同じになるようにしました。 Web アプリケーションを作成する場合に、Web Form と MVC でどのような違いが出てくるのかを理解したかったからです。

 ただし、最初に Web Form として作成した結果、個々の画面は MVC に向いているとはいいがたい点もあると思います。

比較

 ごく短期間に Web Form と MVC とで２つほぼ同等な Web アプリケーションを作成した結果から、この２つの方法を比較してみたいと思います。

 まづ、 Web Form で作成するのは、単純で分かりやすいと思います。 Web アプリケーションを作成する手順を考えてみます。以下のような手順が一般的でしょう。

• 要件定義
  どのような画面構成にするのか・個々の画面においてどのような作業を・どのような手順で行うのかを議論し、必要ならばユーザの承認をもらいます
• プログラム設計
  要件定義で決定した仕様を実現するためのプログラム設計を行います
  プログラム設計をあまり重んじない手法もありますが、かなり限定的な手法（もしくは、プロジェクト自体がかなり実験的であるなど）にとどまると思います
• プログラムの実装
  プログラム設計に従って、プログラム言語による実装を行います
• プログラムのテストと評価
  プログラムの実装が正しいかのテストや、要件を満たしているかなどを評価します

  Web Form の特徴はポストバックでサーバに要求を出し、個々の画面ではイベントで処理が進んでいくことだと思います。この特徴は、要件定義から設計へ、そして実装への各段階にうまく対応しやすい分かりやすさがあります。分かりやすいということは、大事な特徴と思います。 特に、過去に Windows Form や Windows WPF でプログラムを作成してきた経験のある開発者にはなじみやすい手法と思います。

 では、 Web Form の良くない点は何か？ Web Form では特別な設計の方針や実装の方針を持たないため、理解不能であったり、保守が困難なプログラムを容易に作れることだと思います。 これは言葉を替えると、上手な人は上手なプログラムを作成するし、下手な人は下手なプログラムを作るという当たり前のことでしょう。

 では、 MVC フレームワークを採用した場合の特徴は何か？それは、MVC を採用すると決まった時点で、設計や実装方法に一定のルールを強いることだと思います。 そして、そのルールがプログラム開発に役立ち、また十分な柔軟性を備えているのであれば、ルールに従うことによって多くの利益を得る可能性があります。そのため、 MVC で設計・実装するには、あらかじめ学習期間が必要になると思います。 この点は、開発者の所属する組織やプロジェクトの案件の条件にとって問題となる場合もあるでしょう。

 今回、同等の Web アプリケーションを Web Form と MVC で作成した結果を比較すると、 MVC の方がクラス数・画面数が多くなりました。おそらく、別のアプリケーションであっても同じ傾向を示すと思います。 現時点での結論としては、一人の開発者もしくはごく少数の開発者のグループで作業する場合、 Web Form の単純で分かりやすいことが有利に作用することがあり得ます。一方、プロジェクトの規模が大きく、多人数の開発者で作業する場合は MVC のフレームワークを採用する利点があると思います。 そして、 MVC を採用する場合は、より設計フェーズの重要性が増してくると思います。

MVC の難しさ

 Web Form と MVC で作り替えの作業を行ってみて、ここでは MVC のどこが難しいのかを書いてみたいと思います。まずは、一般論から議論します。
 Web アプリケーションに関わらず、 Windows Form であっても Windows WPF であっても、いやしくも画面のあるプログラムであれば View クラスは必須のクラスです。View クラスの必要性に疑問を感じることはないでしょう。
 同じように、経験を積んだエンジニアであれば、今取り組んでいる分野の問題領域を表現した Model クラスの必要性や重要性に疑問を感じることもないでしょう。そして、この２つのクラスは直感的にどのようなクラスが必要かを容易に指摘できる性格を持っています。
 直感的に導き出せないとしたら、そのクラスは実装上の条件や効率などを考慮して作り出されたクラスである場合でしょう。デザインパターンで使用されているクラスなどを想定してください。

 一方、 Controller クラスは直感的に導き出せないクラスだと思います。プログラムの仕様を検討している時点では、このクラスの必要性や機能が明らかではありません。 このようにController クラスは View クラスや Model クラスと違って、抽象化のレベルが１つ上がっていることが難しさの原因だと思います。 Controller クラスとは、どのような役割を担うクラスなのでしょうか？

 Web MVC が成功していると思うのは、 Controller クラスに明確な役割を割り当てることができたことだと思います。

 Web アプリケーションでユーザが最初に意識するのは、そのページの URL でしょう。ちなみに、このホームページの URL は次のようになっています。

						
　　　　　　http://park6.wakwak.com/~hoshina/Aspdotnet/index.html
						
					

 このホームページは固定の html で書かれていますが、もし Web MVC で書かれていた場合、この URL は AspdotnetController の index メソッド呼び出しを意味します。
 URL の記述がそのまま Controller の構造にまで読み替えられるわけです。こうなると、 Controller クラスはあってもなくてもかまわないクラスどころか、プログラムの動作に不可欠なクラスとなります。
 MVC の成功は、この Controller クラスの役割を明確にしたことが一番の理由でしょう。しかしこのことだけからは、Controller クラスは不可欠の役割をもったクラスにはなりましたが、いったいどのような具体的なメソッドを定義し、 そのメソッドを設計したらよいのかは、やはり分かりにくいと思います。
 これ以降の章では、Controller の役割をどのようにしたら導き出せるのか－それも十分に納得できる方法で－を議論していきたいと思います。この点については、主に こちら に書きました。参照してください。

制限

 制限事項として、２つの側面から特別に記述します。

• ホームページに関すること
  このホームページでは記述しない項目について説明します
• 開発手法に関すること
  このホームページで説明している Web Form と MVC プロジェクトで採用した開発手法に関して説明します

ホームページに関すること

 このホームページでは次のような項目に関しては記述しません。それは、よりふさわしい情報が容易に得られますし、情報の陳腐化が早いためです。こうした情報は一次資料に当たるのが確実です。

• ソフトウェアの入手とインストール方法
  Visual Studio 2017 Community をはじめ SQL Server や bootstrap など様々なソフトウェアを利用しています
  これらの入手方法とインストール方法については書きません
  これらに関する情報は、容易に配布元の一次資料をたどれますので、そちらを参照してください
• ソフトウェアの使用方法
  こちらも、配布元の一次資料やさまざまな紹介記事を参照してください
  ただし、トピック的に特別に取り上げたほうがよいと思われた内容は記述してあります
• 設計手法
  ここで紹介しているプログラムは、オブジェクト指向に基づいた分析や設計がなされています
  しかしながら、オブジェクト指向分析やオブジェクト指向設計については触れません
  特別に興味深いと思われた部分に関してだけ、説明してあります
• C# の文法
  C# の文法に関しては全く説明していません
  そうした知識をお持ち、または調べることができる方を前提としています
• .NET や ASP.NET の標準クラス
  Microsoft 社が提供している標準クラスに関しても、例外を除いて説明していません

開発手法に関すること

 今回のプログラムの制限として、 Entity Framework を利用しないという判断をしました。これは、個人的な好みの問題ですが、データベースに関して Entity Framework の方向に進むことに興味を持てないためです。 この方向は　Entity Framework を研究・開発している技術者の趣味が優先されていて、それを利用する側の立場があまり考慮されていないような気がします。Entity Framework はトイプログラムといった小規模の場合には有効であっても、本当にそれなりの規模の実プロジェクトで、有効に機能するかどうかを疑問に思っています。 そのため、今回のプログラムでは採用しませんでした。

 特に、Windows Form、Windows WPF、Web Form のいづれでも、画面用のコントロールはデータベースに関連した DataTable クラスを直接使用するように設計されています。 一方、MVC ではデータベース関連の標準クラスを直接使用することがなく、データベースのレコードからモデルクラスのオブジェクトに変換して利用するようになっています。 そして、この考え方には納得できる点があります。このことから、 Entity Framework が利用されるとしたら、 Web MVC のプロジェクトが一番有力な候補になるとは思います。

  Entity Framework 不採用の決定をしたことから、データベースの検索結果をモデルクラスに変換する処理は、自前で用意することになりました。そこまでするのであれば、 Entity Framework を使用すればよいのにと思う人もあるでしょうが、最大限の自由度を確保しておきたいという考えと、私の好みを優先させました。

 関連する話題は こちら でも書いています。参照してください。