Model View Control
さて、ASP.NET MVCという言葉が先行して出てきてしまいましたが、ご存じない方も多いと思うので（ASP.NETしか開発したことのない方、Windows Formのみの開発経験者など）、簡単にMVCについて解説します。
| 役割 | 概要 |
| Model | データの管理を行うコンポーネント。例えば、LINQ to SQLなどのデータ定義を行うなど |
| View | HTMLの出力を行うコンポーネント。大抵はModelのデータを元に出力 |
| Controller | Modelの操作、Viewへのリクエストの選択を行うコンポーネント。ユーザーからのリクエストに応える処理を一元管理 |
ASP.NETとASP.NET MVCの比較
ASP.NETとASP.NET MVCは仕組みが異なるので、できること、できないことが明確に分かれています。本項では簡単にですが、ASP.NETとASP.NET MVCの比較を見て見ましょう。
| ASP.NET | ASP.NET MVC | |
| MVCでのサイト構築 | 不可能 | 可能 |
| URLルーティング | 対応したWebフォームが必要 | ルーティングルールによりシンプルなルーティングが可能 |
| イベントドリブン | 利用する | 利用しない |
| 単体テスト | 工夫が必要 | 用意に設定可能 |
MVCでのサイト構築がWebFormでできない原因の一つが、一つのWebFormに対してビジネスロジックファイルが最低一つは必要だったことがあげられます。コードビハインドを利用していなくとも、WebForm内に処理を書くことがほとんどです。URLルーティングはリライトUrlMappingsプロパティを利用すれば可能でしたが、簡単にシンプルなURLを実装できませんでした。現在はSystem.Web.Routing名前空間を利用することで、WebFormでもURLルーティングを実装することはできます。詳しくは「どっとねっとふぁんBlog」に書かれているので、興味がある方はそちらを参照してください。
続いて、実装レベルでの比較です。
| ASP.NET | ASP.NET MVC | |
| ポストバック | 利用する | 利用しない |
| ViewState | 利用する | 利用しない |
| アプリケーション形式 | Webサイト/Webアプリケーション | Webアプリケーションのみ |
| ツールボックス | 多用する | 現時点では利用しない |
| コードビハインド | 多用する | ほぼ利用しない |
| JavaScriptライブラリ | 利用可能 | 利用可能 |
| 各ASP.NETの機能 | 利用可能 | 利用可能 |
| 埋め込みコード | 利用可能 | 多用する |
ASP.NET開発からASP.NET MVC開発への変更点について、いくつかポイントを抜粋します。
（1）ポストバック・ViewStateはMVCアプリケーションでは原則利用しない
ユーザーからのリクエストはすべてControllerディレクトリ内のControllerクラスの処理の結果により、表示すべきページが決まります。つまり、ポストの結果、同一のページに戻るポストバックの動作とは異なるサイト構築がMVCには求められます。
（2）ツールボックスはほぼ利用しない
ポストバック・ViewStateを利用しない、サーバーコントロールを利用しないからです。原則ViewPageでは手書きで（VS2008のインテリセンスを利用して）HTMLタグを記述していく必要があります（後述するHtmlHelperクラスという手助けもあります）。
一見手間に感じますが、サーバーコントロールを利用しないことにより、ASP.NET MVCアプリケーションのHTMLソースはすっきりとした表示になります。つまり、デザイナとの連携を取りやすいというメリットもあります。
（3）埋め込みコードブロックの多様
埋め込みコードは「<% %>」で括ることでVB/C#のコードをHTMLソース上で実行できるようになります。ASP.NET MVCではModelで受け取ったデータをViewPageのHTMLソース上で埋め込みコードを利用し表示することになります。この部分はプログラマの力が必要なので、デザイナと連携を取りながら、データ表示の部分の処理を埋め込むことになるでしょう。
（4）各ASP.NETの機能
各ASP.NETの機能は、今までのASP.NETアプリケーション構築の中で利用してきた機能のほとんどを指します（認証・メンバシップとロール、プロファイル、データキャッシュ、セッションなど）。この部分がASP.NET 3.5の上で動作する利点とも言えるでしょう。
