書籍転載：ASP.NET MVC 5 実践プログラミング
ASP.NET MVCとは？
なぜASP.NET MVCを使うとよいのか？ Webフォームの問題点を示し、ASP.NET MVCの特徴とメリットを紹介する。書籍転載の2本目（導入編「1-2」）。
書籍転載について
本コーナーは、秀和システム発行の書籍『ASP.NET MVC 5 実践プログラミング』の中から、特にBuild Insiderの読者に有用だと考えられる項目を編集部が選び、同社の許可を得て転載したものです。
『ASP.NET MVC 5 実践プログラミング』の詳細や購入は秀和システムのサイトや目次ページをご覧ください。
ご注意
本記事は、書籍の内容を改変することなく、そのまま転載したものです。このため用字用語の統一ルールなどはBuild Insiderのそれとは一致しません。あらかじめご了承ください。
1-2 ASP.NET MVCとは？
ASP.NETという巨大なフレームワークを概観し、その中でのASP.NET MVCの位置づけを理解できたところで、そもそも「なぜASP.NET MVCなのか？」という点に、話題を移していきます。
先ほども触れたように、ASP.NETには偉大な先達としてWebフォームがあります。そして、今さら声を大にするまでもなく、Webフォームはよくできたフレームワークです。あまた用意されたサーバーコントロールをはじめ、統合開発環境であるVisual Studioとの強い親和性は、開発者が記述しなければならない定型的なコーディングの大部分を不要にします。
また、イベントドリブン、ビューステート、プロファイル機能といったしくみによって、アプリケーション開発者はHTTP固有の特性に縛られる必要はありません。それこそWindowsアプリケーションを実装するのとよく似た要領で、Webアプリケーションを実装できるのです。しかも、Webフォームではそれだけの機能を提供しているにも関わらず、高い拡張性も合わせ持ち、開発者をフレームワーク固有の機能に縛り付けることがありません。アプリケーション独自に必要な機能があれば、自由にフレームワークの機能を拡張することができる柔軟さを合わせ持ちます。
これだけ魅力的なフレームワークが存在したにも関わらず、また新たにASP.NET MVCなどというフレームワークを持ち出さなければならなかったのはどうしてなのか――純粋にそんな疑問を持つ読者の方も少なくないと思います。
1-2-1 Webフォームの問題点
結論から言ってしまうならば、Webフォームは、その「よくできた特殊性」がゆえにさまざまな問題も孕んでおり、その問題が時代の変化とともに顕在化していった、ということです。その問題点とは、以下のとおりです。
1単体テストを自動化しにくい
Webフォームは、基本的にページ（Pageクラス）を中心にしたフレームワークです。Pageクラスは直接インスタンス化することはできないので、テストにあたってもサーバー環境の準備は欠かせません。
また、イベントハンドラーは、原則として、ユーザーインターフェイスを経由して呼び出す必要があります。ボタンがクリックされた、フォーム要素の値が変更された、グリッド表のある行が選択された、などのイベントは、すべてユーザーインターフェイスの状態がトリガーとなるものです。これもまた、テストを自動化しにくくする要因です。
もちろん、Visual Studioの自動UIテスト機能*4を利用することで、ブラウザー経由でのテスト手順を自動化することもできます。しかし、この方法ではテスト対象のページでコントロールが増えた、名前が変わったなど、わずかな変更でもテストを再設定しなければならないなど、アプリケーションの変更にテストが影響を受けやすいという問題があります。
- *4 自動UIテストについては、以下の記事も合わせて参照してください。
「UIオートメーションを使用したコードの検証」
2Webフォーム固有の概念が多い
サーバーコントロールをはじめ、イベントドリブン、ポストバック、ビューステートなどなど、Webフォームはその性質上、固有の概念を多く持ちます。もちろん、これらの概念（機能）はメリットと裏表というところもあるので、必ずしもデメリットと言いきることはできません。実際、Windowsアプリケーション開発者からすれば、コントロールやイベントドリブンなどの考え方はむしろ親しみやすいものであるはずです。
しかし、非.NET Framework開発者（たとえばJavaやPHP、Rubyなどの開発者）からすれば、Webフォームの世界が一種独特の世界であるのも事実です。これらの概念は理解してしまえば決して難しいものではありませんが、非.NET Framework開発者にとってはやはり精神的なハードルでもあるようです。
3出力を制御しにくい
サーバーコントロールの目的は、出力をブラックボックス化することです。プロパティを設定するだけで、あとはリッチな出力を生成してくれる、開発者はHTML／CSS／JavaScriptを意識しなくても良いのが、サーバーコントロールの世界です。
これはもちろん、サーバーコントロールのメリットなのですが、両刃の剣でもあります。つまり、細かな出力を開発者が制御することは困難です。しかも、悪いことに、サーバーコントロールが生成する出力は、大概、あまり美しくありません。
これは、昨今のクライアントサイド開発におけるトレンドに反します。近年、スタイルシートによるデザインはごく当たり前ですし、Ajax／HTML5の浸透によってJavaScriptによるコーディングの比率は日に日に高まっています。しかし、見通しの悪いHTMLのコードは、JavaScript／スタイルシートによる開発をすこぶる困難にします。
1-2-2 ASP.NET MVCの特徴
以上のような問題を受けて登場したのが、本書のテーマでもあるASP.NET MVCなのです。冒頭触れたように、ASP.NET MVCは従来のASP.NETを基盤に開発された（＝Webフォームとも基盤を同じくする）フレームワークです。しかし、そのアプローチはWebフォームのそれとはまったく異なります。以下では、Webフォームとの違いを意識しながら、ASP.NET MVCの特徴をまとめておきます。
1Model－View－Controller方式を採用
ASP.NET MVCは、名前の通り、MVC（Model－View－Controller）パターンと呼ばれるアーキテクチャを採用しています。MVCパターンとは、要は、アプリケーションを「Model（ビジネスロジック）」「View（レイアウト）」「Controller（ModelとControllerとの橋渡し）」という役割ごとに明確に分離しよう、という設計モデルです。
| 要素 | 概要 |
|---|---|
| M（Model） | データベースへのアクセスなど、データの管理／操作を担当。ビジネスロジックそのものを担当し、ユーザーインターフェイスの変更などにも影響を受けにくい |
| V（View） | ユーザーインターフェイス。データ入力を行うためのフォームや、処理結果の表示を担当するアプリケーションのフロントエンド |
| C（Controller） | ModelとViewとの仲介役。Viewから受け取ったデータをModelに渡し、Modelでの処理結果をViewにフィードバックする |
従来のWebフォームは、ページ（Pageクラス）を中心としたプログラミングモデルでしたが、Webの世界ではこのようなMVCパターンを前提とした開発が一般的です。ASP.NET MVCの設計モデルは、おそらくJavaやPHP、Rubyなどでフレームワークを使った開発を行ったことがある方ならば、ごく親しみやすいものであるはずです。
2フロントコントローラー方式を採用
何度もしつこいようですが、従来のWebフォームはページを中心としたフレームワークです。個々のページでリクエストを受け、その処理結果もページからクライアントに応答します。このような方式のことをページコントローラー方式と呼びます。
ページコントローラー方式では、リクエストURLも基本的にページ（.aspxファイル）の物理的な配置に依存します。たとえば、/Contents/App1フォルダー配下のArticle.aspxに対してクエリ情報date（値は2014-10-31）を渡そうとしたら、
http://www.wings.msn.to/Contents/App1/Article.aspx?date=2014-10-31
のようなアドレスになるはずです。
しかし、ASP.NET MVCではフロントコントローラーと呼ばれる方式を採用しています。フロントコントローラー方式とは、クライアントからのリクエストを一箇所で受け付ける方式のことです。すべてのリクエストは、まずフロントコントローラーを介して、個々のコントローラークラスに振り分けられます。
コントローラークラスについては改めて次章（※転載対象外）で解説しますので、ここでは、
フロントコントローラーから処理を委譲されて、個々のリクエストに応じた処理を行うためのクラス
であるとだけ理解しておいてください。ちなみに、リクエストURLに応じて処理の受け渡し先を決定することをルーティングと言います。
フロントコントローラー方式を利用することで、もはやリクエストURLが物理的なファイル配置に左右されることはありません。ルーティング（振り分け）のための規則さえきちんと決めておけば、たとえば、
http://www.wings.msn.to/Blog/2014/10/31
のようなURLで、Controllers/ArticleController.csに処理を振り分けることができるのです（もちろん、振り分け先はHoge/FooController.csでも構いません）。このURLが、先ほどのURLよりもはるかにシンプルで、また、人間にとって直感的な形式であることは、きっと納得いただけることでしょう*5。
- *5 厳密には、従来のWebフォームでもルーティングは利用できます。ただし、もともとがページ単位のフレームワークであるため、その管理は煩雑になりがちです。
ルーティングに関する詳細は、第7章（※転載対象外）で解説します。
3単体テストを自動化しやすい
先述したように、Model－View－Controllerパターンでは、レイアウトとビジネスロジックとを、従来のWebフォームよりも明確に分離します。
たとえば、ASP.NET MVCでControllerの部分を担うのはコントローラークラスの役割です。コントローラークラスは、普通のクラスと同じ要領で直接にインスタンス化できますので、単体テストのためだけに殊更にサーバー環境を用意する必要はありません。POCO*6をテストする要領でコントローラークラスをテストできます。ビジネスロジックが集約した（しているはずの）Modelについても同様です。
- *6 PlainOldClrObject。特定の環境に依存しない古いCLRオブジェクトのことを言います。
単体テストは、ASP.NET MVCが従来のWebフォームに優位する最大のポイントのひとつです。詳細は第9章（※転載対象外）で改めて解説します。
4サーバーコントロールを使わない
ASP.NET MVCには、イベントドリブンやポストバック、ビューステートという概念はありません。このため、これらの概念を前提に提供されているサーバーコントロールも、ASP.NET MVCでは利用しません*7。
- *7 利用できない、ではありません。ポストバックやビューステートを利用しない範囲であれば、サーバーコントロールを利用することもできます。
ASP.NET MVCのViewでは、動的な値を@...、@{....}のような埋め込みコードを使って表すのが基本です。従来のASP.NETでは、フォームデザイナーからサーバーコントロールをドラッグ＆ドロップするだけでページをレイアウトできていたことを考えれば、これはいささか面倒にも感じるかもしれません。
しかし、これにはメリットもあります。埋め込みコードでは、出力されるHTMLの内容は完全にアプリケーション開発者（またはデザイナー）の責任です。言い換えれば、開発者が意図しないタグが勝手に生成されることはないということです。多くの場合、人間の手によって書かれたコードは自動生成されたそれよりも見通しも良く、結果として、プログラマー／デザイナーの連携も容易になります。
5Webフォームの知識を活かせる
これまでの内容を見ても、従来のWebフォームとASP.NET MVCとでは、基本的な考え方も得手不得手も異なるフレームワークであることが分かると思います。しかし、これまでWebフォームを学んできた方々も嘆く必要はありません。なぜなら皆さんが学んできたことは、決して無駄ではないからです。図1-1をもう一度見返してください。ASP.NET MVCとWebフォームと、どんなに異なるフレームワークに見えても、共通のASP.NETという基盤の上で動作する兄弟分です。
つまり、セッションやクッキー、キャッシュといった、基本的な機能の大部分はASP.NETの知識をそのままに利用できます。当然、.NET Frameworkの基本ライブラリやLINQなどについても同じです。
ASP.NET MVCはそれ自体、シンプルで学習しやすいフレームワークですが、Webフォームを理解している人にとっては、なお一層、学習のハードルは低くなります。
1-2-3 ASP.NET MVCの主な機能
いかがですか。ざっと重要なポイントだけをおさえてみましたが、ASP.NET MVCの全体像、そして、「今から始めるならば、まずはASP.NET MVCを押さえるべき」と述べた理由が、少しずつ見えてきたでしょうか。
ここで、ASP.NET MVCが提供する主な機能をざっと挙げておきます（※第4章以外は転載対象外）。
- ルーティング機能（第7章）
- 認証やキャッシュ、例外処理などのフィルター機能（6-4節）
- 入力データを処理するモデルバインド（6-1節）
- コントローラーの処理結果を管理するActionResultオブジェクト（6-2節）
- ビュー開発を効率化する種々のヘルパーメソッド（第4章）
- アプリケーションの骨格を自動生成するScaffolding機能（第3章）
こうしてみると、ずいぶんとシンプルなフレームワークだと思えませんか。その通り、ASP.NET MVCが提供する機能の大部分はModel－View－Controllerのうち、Controllerと（少しだけの）View機能です。Modelに必要な、たとえばデータベースアクセスのような機能は、.NET Framework本体が提供していますし、Controllerに必要な機能の多くも（先述のように）従来からのASP.NETの機能で賄えてしまうからです。
ASP.NET MVCフレームワークの魅力とは、実に、この絞り込まれたシンプルな機能の範囲で、アプリケーション開発に必要な汎用的な機能が過不足なく織り込まれている点にあると言えるでしょう。
※以下では、本稿の前後を合わせて5回分（第1回～第5回）のみ表示しています。
連載の全タイトルを参照するには、［この記事の連載 INDEX］を参照してください。
1. ASP.NETの全体像
ASP.NET上で動作するWebアプリケーションフレームワーク「ASP.NET MVC」とは？ その全体像と6つの構成要素について紹介する。書籍転載の1本目（導入編「1-1」）。
2. 【現在、表示中】≫ ASP.NET MVCとは？
なぜASP.NET MVCを使うとよいのか？ Webフォームの問題点を示し、ASP.NET MVCの特徴とメリットを紹介する。書籍転載の2本目（導入編「1-2」）。
4. フォームを生成する - BeginFormメソッド［Razor］
＜form＞要素を生成するには、標準のビューヘルパーとして提供されているBeginFormメソッドが便利だ。その使い方を解説。書籍転載の4本目（基礎編「4-2-1」）。
5. ルート定義からフォームを生成する - BeginRouteFormメソッド［Razor］
ポスト先のルートパラメーターを指定した＜form＞要素を生成できるBeginRouteFormメソッドの使い方を解説。書籍転載の5本目（基礎編「4-2-2」）。
