WebアプリケーションにおけるMVC

 ここまではGUIアプリケーションにおけるMVCの例を見てきました。では,Webアプリケーションにおいて,MVCはどのように働くのでしょうか。

 まず,前回学んだWebアプリケーションの基本となるHTTPについて思い出してみましょう。HTTPの1回のやり取りは次の(1)から(3)のように流れていきます。

(1)Webブラウザはユーザーからの操作に応じてソケットを経由し,WebサーバーにHTTPリクエストを送る。

(2)Webサーバーはリクエストに従い,Webブラウザに送るデータを用意する。

(3)WebサーバーからWebブラウザにHTTPレスポンスという形式でデータが送られる。

 これをMVCパターンに当てはめると,次のようになります。

(1)Webブラウザから送られたHTTPリクエストは(Webサーバーを経由して)コントローラに渡される。Webアプリケーション・フレームワークのディスパッチャ(振り分け機構)がリクエストを適切なコントローラに渡す。

(2)コントローラはリクエスト内の情報に基づいてモデルを操作する。同時に,表示に用いられるビューを指定する。モデルから起動されたビューはモデルを参照しながらWebブラウザに送るデータを構築する。

(3)WebサーバーからWebブラウザにHTTPレスポンスという形式でデータが送られる。

 制御の流れが比較的複雑なGUIアプリケーションと違い,1つのリクエストに対して1つのレスポンスが返るというHTTPでは,コントローラとビューに明確な処理順序が発生します。

 図7にMVCを用いたWebアプリケーションの代表として,Ruby on RailsのMVC構成を示します。ただし,RailsはMVCを採用しているといわれているものの,その用法は従来のMVCパターンとは微妙に異なっています。

図7●WebアプリケーションにおけるMVC
図7●WebアプリケーションにおけるMVC
Ruby on Railsの場合。

 Railsにもモデル,ビュー,コントローラという存在があり,それぞれ独立したディレクトリに格納されています。Railsアプリケーションを構成するディレクトリにはappというサブディレクトリがあり,その下にさらに以下のようなディレクトリが配置されています。ヘルパーとは支援ルーチンのことです。

app/models モデル
app/views ビュー
app/controllers コントローラ
app/helpers ヘルパー

 ここまで説明してきたMVCパターンでは,モデルがビジネス・ロジック,コントローラが入力制御,ビューが出力制御,という役割分担でした。Ruby on RailsにおけるMVCの分担は少し異なります。Railsでの分担はモデルが「データベース層」であり,ビューが「表示用テンプレート(eRuby)」,コントローラが「制御用クラス(アプリケーション・ロジックを含む)」となっています。

 従来のMVCパターンとRailsのMVCパターンを比較すると,おおむね表2のような対応になるようです。ちょっとずれていますね。

表2●従来のMVCとRails MVCの比較
表2●従来のMVCとRails MVCの比較

 元々,Webアプリケーションでは三層モデルというシステム構成が広く受け入れられていました。三層モデルとは,ユーザー・インタフェース(UI)層,ビジネス・ロジック層,データベース層の三層です。旧来のMVCモデルではビジネス・ロジック層とデータベース層が一体になってモデルと呼ばれていましたが,これはSmalltalkがあまり外部のデータベースを利用しなかった(永続化機能はシステムそのものが持っていた)ことと無関係ではないでしょう。

 一方,HTTPの性質によってUI部分の複雑さはWebブラウザに任せてしまっているWebアプリケーションでは,相対的にUI層が薄くなります。コントローラ相当はほぼ汎用品で十分ですし,モデルとビューのインタラクションも不要です。ですから,モデルをデータベース層とビジネス・ロジック層に分割して,下層をモデル,上層をコントローラと呼ぶようにしたのでしょう。

 実際,Railsのコントローラはビジネス・ロジックだけでなく,本来のコントローラが行っていた制御も一部担っていますから,全く的外れな名称とまでは言えません。

 同じMVCを掲げながら,それぞれの役割が微妙に異なるというのは,なんだかややこしい話ですが,歴史的な事情によるのかもしれません。

 単語の意味が少々異なっていることは,やや面倒です。ただし,Railsが採用している(旧来のMVCとは異なる)役割分担が間違っているわけではありません。Railsが支援するようなデータベース中心のアプリケーションの構築にはビジネス・ロジックとデータベース操作を一体にして「モデル」と呼ぶよりも,きちんと分割した方が保守性が高くなります。だからこそ三層モデルが登場していたわけですね。

 このことについては,今後Railsを解説する際に詳しく説明できればと考えています。

出典:日経Linux 2006年12月号 157ページより
記事は執筆時の情報に基づいており、現在では異なる場合があります。

この先は会員の登録が必要です。今なら有料会員(月額プラン)登録で6月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら