JavaScriptにおける、MVCフレームワーク以外の選択肢

2012年11月26日

JavaScriptではさまざまなフレームワークが登場していますが、最近注目を集めているのがMVCアーキテクチャの実現を容易にするMVCフレームワークです。Publickeyでも以下の記事などで紹介してきました。

しかしプログラミングの世界では、MVCアーキテクチャ以外にもさまざまなデザインパターンがあります。JavaScriptプログラマはもっとそれらを検討すべきだ、という記事「The World Beyond MVC」（MVCの向こうにある世界）が、The David Walsh Blogにポストされました。

気になる記事だったのでDavid Walsh氏と著者のGarann Means氏に、日本語訳をしていいか尋ねたところ、快諾いただきました。ここでその日本語訳を公開したいと思います。

The World Beyond MVC

MVCの向こうにある世界（The World Beyond MVC）

いま数多くのJavaScript MVC（Model-View-Controller）フレームワークが存在している。いちばん有名なのはBackboneだが、ほかにもSpine、Agility、Knockbackなどがある。こうしたフレームワークはとても人気で、執筆時点でGitHubの人気プロジェクトの7番目にはBackboneが入っている。デベロッパーはMVCがとても好きなのだ。

MVCフレームワークがJavaScriptで注目されている理由は何だろうか？もしあなたがアプリケーションアーキテクチャをこれから学ぼうとするならばMVCアーキテクチャの情報はすぐ見つかるだろうし、もしもサーバサイドのコーディングをしたことがあるならば、おそらくMVCアーキテクチャの知識をすでに持っているだろう。

ほとんどのオブジェクト指向プログラミング（OOP）はMVCアーキテクチャに対応するし、Javaや.NET、Python、PHPなどではMVCフレームワークはとても一般的だ。MVCアーキテクチャはもともと、Tryvge Reenskaug氏が70年代後半に発明し、その後Smalltalkで初めて実装された。だから最初からMVCアーキテクチャはOOPと関係があったし、その優位性は疑いようもなかった。だからMVCアーキテクチャが広く認知されていたとしても驚くことではない。

JavaScriptはしかし、正確にはOOPではない。OOPが可能ではあるけれど。JavaScriptにおいてMVCアーキテクチャが適切な選択であるかどうかは、ユースケースによって変わりうる。

データの入力やコンテンツ管理といった、Modelを明確にできる場合にはMVCアーキテクチャはうまく行くだろう。しかしアプリケーションのステートがもっと多様でさまざまな動作を行い、データ操作以前にユーザーとさまざまなやり取りが発生するような複雑なアプリケーションでは、MVCアーキテクチャが適切な選択かどうかは明らかではない。

ただ、たとえJavaScriptを多用していても、もしあなたのWebサイトがスタティックならばMVCアーキテクチャのことは忘れていい。ページをリロードすると全部消えてしまい、大したメリットはないのだから。

MVCアーキテクチャ以外にも選択肢はある

MVCアーキテクチャやそのほかのパターンについて語ろうとするときに問題になるのは、もともとこれらのパターンが私たち（JavaScriptプログラマ）のために作られたものではない、ということだ。その一般的なパターンの多くは、1995年に刊行されたいわゆるGang of Fourの本（日本語版は「オブジェクト指向における再利用のためのデザインパターン」）で見ることができる。

そしてこれらのパターンはプログラマ自身のために作ったものであり、クリックしてソースがすぐ見えてしまうようなプログラマのためのものではなかったし、バックエンドのような形式でのプログラミングに合わせて作られていた。

MVCはしかし、現在のこの分野でも認知されている。というのも、ユーザーインターフェイス、あるいはフロントエンドという適用しやすい部分があったためだ。私たちJavaScriptプログラマが利用したいアーキテクチャは、私たちの目的に合致していれば多少の間に合わせでもよく、MVCは手始めにはとても優れたものだった。

しかしMVCアーキテクチャ以外にも選択肢はあるのだ。

Event-Drivenアーキテクチャ

Event-Drivenアーキテクチャは、MVCアーキテクチャの次によく知られたパターンと言っていいだろう。これはJavaScriptのあらゆる場面で使えるし、MV*アーキテクチャと組み合わせることもできる。

多くのメッセージングが必要なところででうまく働くが、クラシカルなオブジェクトではあまり必要としない。オブジェクトのためにはgetterとsetterがあり、（そしてまもなくObject.observe()も）、これを使うことでPublishersとSubscribersとして、イベント、アプリケーションのコアから、オブジェクトの影響を分離できる。

Event-Drivenの価値は、分離されたイベントが、オブジェクトだけでなくDOMやサーバとのやり取りやほかのイベントと作用しないようにでき、Model-View-Controllerの3本柱に結びつける必要もない、ということだ。

Naked Objectsパターン

Naked Objectsパターンは、MV*と近い関係で、Presentation-Abstraction-Controlの一種と呼んでもいいだろう。これは、大きなウィジェットのような、自身で内容を持ち、そのビジュアルがデータに直接結びついていて、それを自身でレンダリングする必要のある大きなウィジェットなどに適している。

Rebecca Murbpheyは似たようなパターンを「Mulberry」モバイルアプリケーションのフレームワークで使っている。Naked Objectsは異なったパターンによって実装されたフレームワークを組み合わせるのに優れた方法であり、うってつけのユースケースだといえる。

Pipelinesパターン

3つめのパターンと考えられるのがPipelinesだ。これはjQueryデベロッパーやコールバックを多用するデベロッパーにはおなじみだろう。パイプラインのチェーンオペレーションは、ビジュアルやデータセット（あるいはその両方）の状態に対してまとめて作用する。

私にとって興味深いのは、このパターンは同期、非同期のどちらにも使えるということだ。例えば、グローバル関数でイニシャライズ、レンダリング、ページの枠組みを整え、そしてインスタンス固有の関数でユーザーの操作を待ち、それをバリデートし、セーブし、再レンダリングする。こうした操作はすべて、ページの内容の状態に対して行われる。コードの中に、状態に関する変更内容が含まれており、各ステップの結果ごとに処理が進んでいく。

何も使わないよりはBackboneを使う方がいい

こうしたことはすべて、MVCやほかのパターンと一緒に、アプリケーションを密結合にしたいのか疎結合にしたいのか、そしてアプリケーションの中心で状態を持ちたいのか、関連コンポーネントの中にもったほうがいいかということと共に検討されるべきだ

Naked Objectsのようなパターンは、たとえ複雑なコントロールであっても一度しか使わないコードには締め付けが強すぎるし、もしもコードの大半が初期化などを目的とするならEvent-Drivenパターンは適切ではない。

まとめると、何も使わないよりはBackboneを使う方がまだいいだろう。なんにせよ、もしもあなたがアプリケーションに適切なパターンを見つけたなら、それを使うのを恐れることはない。ただ残念ながら、多くのパターンにおいてBackboneほど強力で導入しやすいフレームワークを見つけるのは簡単ではない。

だから、もしあなたがMVCフレームワークの代替になるものを探したり、作ろうとするならば、それは私たちすべてにとって役に立つ行為になる。そしてどのパターンを選択しようと、あるいはどんなアプリケーションであっても、実装に隙はあるし、それはアーキテクチャの進化の余地があることであり、コードを進化させる余地がある、ということを忘れてはならない。

オブジェクト指向における再利用のためのデザインパターン
オブジェクト指向ソフトウェア設計の際に繰り返し現れる重要な部品をデザインパターンとして記録し、カタログ化。改訂版ではこれにCD-ROMを添付、現場でブラウザを通して即利用できるパターンカタログデジタル版を収録。特別付録として、原書にはないJavaのサンプルコードを追加。