MVCとは？GUIやWebアプリケーションの設計方針とその派生形について

MVC（Model-View-Controller）は、ソフトウェア設計における一つの考え方です。もともとはGUIをもつアプリケーションのために考案されたものでしたが、現在ではWeb開発にも広く取り入れられています。

一方、時代の変遷とともに少しずつ形を変えてきたことから、理解が難しくなってしまった部分も少なくありません。そこで今回は、あらためてMVCの基本的な考え方を整理したうえで、その派生形について紹介していきます。

MVCとは

まずはMVCの本来の目的と、これまでの変化の歴史について説明します。

MVCの目的

MVCは、1970年代に登場したプログラミング言語「Smalltalk」で、GUIアプリケーションを設計するために考案されました。MVCではアプリケーション全体を「M（＝モデル）」と「V（＝ビュー）」、「C（＝コントローラー）」の3種類の要素に分割します。それぞれが決められた役割を果たしながら連携することで、ユーザー入力から画面表示までの一連の処理を進める仕組みです。

この手法には、各要素が互いに影響しにくいというメリットがあります。

例えば、GUIの見た目や使い勝手を変更しても、その影響がビジネスロジックにまで波及することは通常はありません。そのため、開発を分業していてもアプリケーションを改善しやすくなります。このようなMVCの考え方と特徴は広く受け入れられ、のちにさまざまなバリエーションが生まれることとなりました。

MVCの歴史

MVCが広く知られるようになったきっかけは、今から30年以上もさかのぼる出来事です。1988年、デザインパターンに関する書籍でSmalltalkのMVCが紹介されました。本書は日本でも「オブジェクト指向における再利用のためのデザインパターン」（1995年に初版発行）というタイトルで出版されており、日本語でも読むことができます。

その4年後の1992年には、Microsoft社から初のC／C++コンパイラが発売されました。製品に付属のライブラリ（MFC）とともに、MVCと似た構造をもつDocument-Viewが登場します。

1999年になると、JSP（JavaServer Pages）のサーバーサイドにMVCが取り入れられました。この出来事が、Web開発におけるMVCの本格的な活用のさきがけだったといわれています。

そして2006年には再びMicrosoft社から、MVCをさらに前進させたMVVMが発表されました。このような歴史を経て、MVCとその派生形は現在でも幅広く活用されています。一方、「MVC」という用語が実際に何を指しているかは、文脈によって異なるのが現状です。

古典的MVCの構成要素

Smalltalkに由来する本来のMVCにおいて、3種類の構成要素がどのような役割を果たすのかを説明します。

モデル（Model）

「モデル」という名前から、データモデルを連想する人も多いかもしれません。しかし、MVCにおけるモデルとは、データとビジネスロジックをカプセル化したもののことです。GUIの構成などに左右されにくい抽象度の高いメッセージを受け取り、必要に応じてデータを更新する役割を担います。

また、データの更新状況をビューに通知するのもモデルの責務です。ただし、デザインパターンの「Observer」などを用いて、ビューに依存しない作りにしなければなりません。ビューにもコントローラーにも依存しないというのは、モデルがもつ重要な性質です。

ビュー（View）

「ビュー」の役割は、モデルから受け取ったデータをユーザーに見せることです。端的にいえば、ディスプレイへの表示がビューの責務にあたります。

ビューはGUIを構成するテキストやボタンなどのパーツに相当するため、階層構造をもつのが通常です。ただし、Webのサーバーサイドに応用する際は、そうとも限りません。この場合、最終的な画面表示はブラウザが行なうため、HTMLなどのレスポンスを生成するところまでがビューの役割です。

ビューは、データを取得するためにモデルに依存しています。一方、データをどのように描画するかは、ビューの裁量に委ねられる部分です。例えば、同じ数値データでも、目的に応じてテキストで見せたいのかグラフにしたいのかが変わってくるでしょう。画像の場合でも、全体を見せたいのか一部を拡大表示したいのかといった違いが考えられます。

コントローラー（Controller）

「コントローラー」は、ユーザーによる操作を受け付け、それらを適切なメッセージに変換してモデルに伝達します。端的にいえば、マウスやキーボードからの入力イベントを処理するのがコントローラーの責務です。

コントローラーには、自身がビジネスロジックをもたないという特徴があります。モデルの手前に位置し、プロキシのような役割を果たすものだといえるでしょう。

理想的な意味においては、コントローラーが依存する対象はモデルのみです。しかし、どのボタンがクリックされたのかなどを知る必要があるため、現実的にはビューにも依存します。このとき、ビューによる描画をコントローラーが直接引き起こすことはありません。コントローラーが影響を与えて良いのは、あくまでモデルのみということです。

MVCから派生した設計

ここからは、Smalltalkに由来する古典的なMVCがたどった変化について、代表的な例を紹介していきます。

ドキュメント／ビュー（Document-View）

GUIのアプリケーションを設計する際、ビューとコントローラーを完全に分離するのは簡単なことではありません。ユーザーは画面を通してアプリケーションを操作するためです。また、ウィンドウシステムを搭載したOS上の開発ではマウスやキーボードのイベントを画面と連動させるのも簡単になり、コントローラーの存在意義が薄れてきました。

このような背景のなか登場したのが、「ドキュメント／ビュー」です。ドキュメント／ビューの「ビュー」はMVCにおけるビューとコントローラーを結合させたものであり、画面表示とユーザー入力の両方の処理を受け持ちます。ドキュメント／ビューの「ドキュメント」は、通常はドキュメントファイルとして保存可能な一連のデータに対応付けられ、MVCにおけるモデルに相当する部分です。

MVVM（Model-View-ViewModel）

MVVMの「ビュー」は、ドキュメント／ビューの「ビュー」と同様、MVCにおけるビューとコントローラーの両方の役割を果たすものです。これにより、ユーザー操作はビューを通じてモデルに伝達され、モデルの更新はビューへの通知によって画面表示に反映されます。

GUIが十分に単純であれば、モデルとビューの処理は1対1で対応付けられるでしょう。しかし、実際のGUIでは、すべての操作をモデルへの1つのメッセージに対応させることは困難です。画面表示も、常にモデルの更新のみによって行なわれるとは限りません。現実的には、ビュー自身がビジネスロジックとは別に何らかの制御を行なう必要があるということです。

MVVMでは、「ビュー」と「モデル」の間に「ビューモデル（ViewModel）」を配置することで、このような問題を解決します。ビューが必要とする状態をビューモデルが管理し、モデルの手前に入って調整役となることで、全体をシンプルに保つのです。

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

Web開発においては、コントローラーの役割を変更したMVCが主流となっています。リクエストの受け取りとレスポンスの生成を1ヵ所でまとめて行なうほうが、サーバーサイドでは都合が良いためです。

サーバーサイドのコントローラーの役割は、モデルとビューを含む全体をコントロールすることだと考えればよいでしょう。コントローラーはリクエストを受け取ると、まずURLやフォームの内容に応じてモデルを呼び出します。次にビューを呼び出し、モデルから取り出したデータをもとにHTMLなどを生成するという流れです。

このようなMVCがJSPのサーバーサイドに取り入れられて以降、ほかのフレームワークでも同様の方式が採用されるようになりました。おもな例としては「ASP.NET」や「Laravel」、「Ruby on Rails」や「Spring」などが挙げられます。

MVCは姿を変えながらアプリケーション開発に影響を与え続けている

MVCは、GUIをもつアプリケーションの開発において、その構成要素を種類に分けて設計するための考え方です。アプリケーションの部分的な改善や変更が、ほかの部分にまで波及することを防ぐメリットがあります。

時代とともに古くなってしまった部分はあるものの、MVCは多くの開発者に受け入れられ、ドキュメント／ビューやMVVMなどの派生形を生み出しました。現在では、Webアプリケーションの開発にも広く取り入れられています。登場以来30年以上経った今でも、アプリケーション開発に影響を与え続けている方法論だといえるでしょう。