新しいフレームワークを基礎から学ぶ。ASP.NETの魅力を表すキーワードについては、すでに多くの記事によって語り尽くされているところでもあり、本稿であえて繰り返すまでもない。2005でいってみようDBプログラミング」などを併読していただくとよいだろう。そんなASP.NETにも問題がないわけではない。1つに、単体テストの実施が容易でないという点。諸兄もご存じのように、Webフォームは基本的にページ(Pageオブジェクト)がベースになっている。Pageオブジェクトは直接インスタンス化することはできないので、単体テストを行うにも実行時と同様のサーバ環境を用意しなければならない。イベント・ハンドラを呼び出すために、ユーザー・インターフェイスを経由する必要があるのも、テストの自動化を阻害する要因だ。ブラウザの動作を自動化することで、テストそのものを自動化することができないわけではない*1。このアプローチでは、コントロールのID値を1つ変更しただけで、テストも再設定しなければならないなど、変更に対して脆弱過ぎるのだ。具体的な方法については、CodeZineの記事「VSTTのWebテスト機能でアプリケーション品質を強化する」も参考になる。1つに、ASP.NETにはとかく固有の概念が多い。Windowsアプリケーション・ライクなイベントドリブン・モデルを始め、ポストバックやビューステート、サーバ・コントロールなどの概念は、恐らく非.NET分野の開発者からすれば、一種独特のものに感じるはずだ。後者については、メリットとも背中合わせであり、一概にデメリットとだけいい切ることはできないが、Webの世界ではよりメジャーなMVC(Model−View−Controller*2)スタイルでの開発を.NETの世界でも行いたいという要望は、これまでにも多く寄せられていた。Solutionの記事「フレームワーク・プログラミングの準備」などを参照いただきたい。MVCは、ASP.NETをベースに開発されたMVCスタイルのフレームワークである。MVCとでは根本的に仕組みが違うため、得手不得手や、そもそもできることとできないことが明確に分かれている。以下に、両者の主な違い、共通点をまとめてみよう。MVCには、基本的にポストバックやビューステート、イベントドリブンという概念は存在しない。MVCでは使わないのが基本だ。MVCでビューを記述するには、埋め込みブロック(<%......%>)を使用する必要があるのだ。このスタイルは、これまでのサーバ・コントロールをフォーム上にドラッグ&ドロップするというスタイルに慣れてしまった諸兄にとっては、恐らく回りくどく感じることだろう。サーバ・コントロールを利用しないことでメリットもある。MVCが出力したHTMLソースは、従来型ASP.NETのそれよりもすっきりするという点だ。HTMLソースがクリアになれば、おのずとデザイナとの連携が取りやすくなるという効果も期待できる。従来型のASP.NETでは、個々のページ(.aspxファイル)でリクエストを処理する——いわゆる「ページ・コントローラ方式」を採用している*3。リクエスト時のURLも「.aspx」ファイルの物理的なパス構造に左右されていた。Strutsフレームワーク徹底比較[前編]」でも触れている。興味のある方は参照いただきたい。「/Contents」フォルダ配下のForm.aspxに対して、クエリ文字列「isbn」(値は108)を渡そうとすれば、http://www.examples.com/Contents/Form.aspx?isbn=978-4-8443-2699-1のようなURLを指定する必要があった。MVCの基本は、「フロント・コントローラ方式」である。フロント・コントローラとは、クライアントからのリクエストを1カ所で受け取る仕組みのこと。すべてのリクエストは、フロント・コントローラを経由して、個々の「コントローラ・クラス」に振り分けられるわけだ。コントローラ・クラスとは、フロント・コントローラから処理を委譲されて、個別のリクエストに応じた処理を行うためのクラスである。MVCがMvcHandlerクラス(System.Web.Mvc名前空間)として提供しているので、アプリケーション開発者が実際に開発を行う必要があるのはコントローラ・クラスの部分である(詳細は後述)。このとき、リクエストURIに応じて処理の受け渡し先を決定することを「ルーティング」という。リクエストURIを、あらかじめ決められたルールに基づいていくつかのパラメータに分解し、その内容に従って適切なコントローラ・クラスを選択すること——といい換えてもよいかもしれない。先ほどの例であれば、Form.aspxに処理を渡すために物理的なフォルダ構造に左右される必要はない。適切なルーティング・ルールを決めてさえいれば、例えばhttp://www.examples.com/Book/Details/978-4-8443-2699-1のようなURLによって、Form.aspxに処理を引き渡すことができる。このようなURLが、先ほどのURLに比べるとはるかにシンプルで、人間にも読みやすい形式であることがお分かりいただけるだろう(このURLが、ISBNコードが「978-4-8443-2699-1」である書籍の詳細情報を示していることが直感的に理解できる)。[参考]従来型のASP.NETにおけるルーティング厳密には、このようなルーティングは従来型のASP.NETでもできないわけではない。ページ・コントローラ方式である従来型ASP.NETにルーティングの考え方を持ち込むには、いくらかの(少しだけ面倒な)準備が必要となる。MVCでは、標準でルーティング処理を有効にしているので、何ら難しいことを考えることなく、「シンプルで分かりやすいURL」を実装することができる。MVCとでは相当に異なるフレームワークであることがお分かりいただけると思う。MVCを理解するために、すべてを一から学び直さなければならないわけではない。MVCでもそのまま使える。MVCはASP.NETをベースとしたフレームワークなのである。MVCを使った具体的な開発を行ってみることにしよう。MVCによる基本的な開発の流れと、従来型のASP.NETとの違いを感じ取っていただきたい。MVCは、別に従来のASP.NETを置き換えるものではない。MVCはASP.NETの問題点を解決するために登場したフレームワークであるが、すべての問題を解決する“銀の弾丸”であるというわけではないのである。MVCはWebの世界ではメジャーなMVCスタイルを採用しているので、従来、非.NET環境でWeb開発を行ってきた人間にとっては、なじみやすいフレームワークであるはずだ。BasicやC#でWindowsアプリケーション開発を行ってきた人間にとっては、HTTP固有の制限を限りなく隠ぺいしている従来のASP.NETの方が圧倒的に理解しやすいだろう。MVCではより「きれいな」出力を期待できる。MVCの大きな制限であるといえる*4。MVCとは、求める効果や、そもそも自分の得手不得手に応じて使い分けるべき、対等な選択肢なのである。これは将来的にMVC向けのコントロールが提供されることで解決するかもしれないが。1」を適用しておく必要がある。SP1新機能解説」も参照いただきたい。MVCをインストールしてみよう。MVCは、以下のページからダウンロードできる。1.0ダウンロードした「AspNetMVC1.msi」をダブルクリックするとインストーラが起動するので、後はウィザードに従って進めるだけでよい。特別にオプションを指定するところもなく、ウィザードに従って進めるだけでよい。特別にオプションを指定するところもないので、インストールそのもので特に悩むところはないはずだ。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。