トップ » 技術記事 » 使い勝手の再利用をアーキテクチャの視点から考えてみる

使い勝手の再利用をアーキテクチャの視点から考えてみる はてなブックマーク数 このエントリーをブックマークに追加

どうも、あかさたです。今回は、「ユーザインタフェースとアプリケーションは分離する」に関係して、アプリケーション開発者の手を離れはじめたユーザビリティのモジュールを MVC や依存性の注入などの設計技術の観点から考察してみます。

はじめに

本記事を書くきっかけとなったのは、「ユーザインタフェースとアプリケーションは分離する」のブックマークコメントに、以下のような質問があったことです。

MとVCを分けるより、VとMCが自然と分かれた。。。という感じ?

これは大変面白い問題意識です。「UI に関するモジュールがアプリケーションから切り出された」ということは、「何らかの事情でそれまで再利用されてなかった処理が、技術的な変化で再利用できるようになった」ということです。多くの場合、再利用を妨げるのはモジュール間の依存関係です。アーキテクチャパターンの視点から問題を整理して、どのような変化があったのか理解することは大切なことです。

本記事では、設計技術的な観点から「使い勝手の再利用」を考察してみます。

ウェブアプリケーションと MVC

MVC(Model-View-Controller)はアーキテクチャパターンです。多くのウェブアプリケーション、スタンドアロンアプリケーションは MVC を元にしたフレームワークを使って開発されています。

ウェブアプリケーションの世界では、MVC は入力(HTTPリクエスト)をコントローラが受け取って、モデルで処理してから、ビュー(HTML など)をレスポンスとして返すというような動作をします。スタンドアロンの世界では、ウェブアプリケーションと異なり、ビューを介す入力があったり、相互に依存し合うことがあるため少し複雑ですが、基本的には同じような動作をします。

ブックマークコメントにあった「MとVCを分けるより」という話は、MVC にあっては古典的な関心事といえます。というのは、MVC では、入力(コントローラ)と出力(ビュー)は密接に関わり合うため、ビューとコントローラを明確に分けられないことが少なくないからです。

事実、ウェブの MVC フレームワークを使っていても、実際にコードを書く際に、コントローラにビューの処理を書いてしまうことは多々あります。あるいは、素の PHP を書くならビューにコントローラに記述すべき内容を書くことが多くあります。

ビューとコントローラを強く分けない M-VC なアプリケーションというものは、スタンドアロンアプリケーションでもよく見かけます。こうしたアーキテクチャを MVC のバリエーションとして Document-View(M が Document、VC が View)パターンといったりもします。

ではブックマークコメントの「VとMCが自然と分かれた」という話はどこから来たのでしょう。一つ一つ掘り下げてみましょう。まず、Ajax が流行始めた頃に「処理は何でもあちら側に」というような風潮がありました。(今でもないわけではありませんが。)まずは、サーバ側にモデル(処理)を持って行くという考え方で図にしてみます。

サーバをモデルと見立てた場合

図 1「サーバをモデルと見立てた場合」

サーバをモデルと見立てて、VC+M になりました。水色はサーバ、赤はクライアントです。上図には、サーバ側の構造が反映されていません。サーバ側も MVC で開発されているので、図にサーバ側の MVC を反映してみます。

サーバ側の構造を加味した場合

図 2「サーバ側の構造を加味した場合」

サーバ側から見れば、クライアントがどうあるかに関わらず、MVC の形はそのまま維持されていることがわかります。Ajax が多用されているサイトは大抵このような構造を持っています。

さらにリッチなクライアントの場合も考えてみましょう。リッチクライアントの場合、処理の一部はクライアントで行われます。たとえば Flash は MVC(Document/View)前提のフレームワークが準備されるので、クライアントでも MVC、ウェブサーバでも MVC という構造になる場合もあります。Flash はサーバとはほとんど別のアプリケーションとして開発されるので、こうした構造はそれほど違和感がありません。図に反映してみましょう。

クライアントの MVC とサーバの MVC

図 3「クライアントの MVC とサーバの MVC」

※ 図 3 では便宜上、サーバが出力したビューの上にクライアントを乗せていますが、サーバが生成したビューとは独立するクライアントも多々あります。というより、リッチになればなるほどその傾向は強まります。

ウェブアプリケーションには、図 2 のようにモデルを持たないクライアントと図 3 のようにモデルを持つクライアントとがあります。GreaseMonkey スクリプトの AutoPagerize や LDRize にせよ、Twitter クライアントなどの専用クライアントにせよ、クライアント側の MVC を薄くしたり、置き換えたりするものです。

つまり、「VとMCが自然と分かれた」という話は、MVC が V+MC というように分離するというよりは、V をさらに細かく見ると、サーバのビュー(出力)とクライアントの MVC が含まれていて、サーバのビューからクライアント側を切り離すという大きな文脈があるという話になります。

次に、クライアントの MVC を掘り下げてみましょう。


1 2

このサイトについて

八角研究所
株式会社八角研究所のWEBサイトですよー。 いろんなものを創り出すことのできる環境をコツコツ構築中。 いったい、いつになったらできるのか。 この技術情報サイトもそのための活動の一環のつもり。

執筆者紹介

あかさた

あかさた

未踏(2006年度下期)でWeb上で動作するモデリング環境 Kodougu の開発をしてました。こちらでもブログを書いています。

TrackBack URL :