共通認識として、Ruby on Rails のような Model2 っぽいフレームワークを使う場合、“重い Model と軽い Controller” にするべきとされている。すべてのアプリケーションに当てはまるわけではないが、実際に著者が見てきたアプリケーションもだいたいそうだった。伝統的な MVC の Controller の中では View からの入力を注意深く監視して反応するためにビジネスロジックで重くなりがちなので、この決定は納得のいくように見える。

HTTP のステートレスな性質を考えると、Model2 の View は本当に一時的なものだ。**どんな状態もリクエストさえまたいでしまえばビュー自体に保持されることはない。**ほとんどのサーバサイドのフレームワークでは、どんなアプリケーションの状態もセッション・クッキーを通して保存されている。だから Controller から View へは一方通行でしか情報を伝えられなくしたのは非常に論理的だが、フロントエンドの開発にとってはあまり適していない。

MVP と MVVM

Model-View-Presenter パターンと Model-View-ViewModel パターンは両方とも伝統的な MVC パターンに似ているが、いくつかの重要なちがいがある：

• View は Model を直接参照できない
• Presenter (または ViewModel) が View への参照をもち、Model が変更されたら View を更新する

MVPパターンは Martin Fowler によって詳細に論じられており (これやこれ)、だいたいは 2 つの実装上の観点から論じられている：

• 受動的な View：設計上、View はできるかぎり素朴であるべきで、絶対的で必要とされる表示 (presentation) やビジネスロジックは Presenter に含まれるべきだ
• 監督者としての Controller：View で何か宣言すればそれが単純なロジックも内包しているようなシステムで利用される。このようなおまじないの中では、View の中の宣言的なロジックがシステム要件を満たすことができないときだけ、Presenter が処理を引き継ぐ

Figure 4: Model-View-Presenter

Figure 5: Model-View-ViewModel

MVP と MVVM はほとんど区別がつかないが、1 つの重要な例外がある：MVVM は ViewModel 内の変化が頑丈なデータ・バインディング・エンジンによって View に反映されることを前提としているのだ。Niraj Bhatt がこの違いについて「MVC vs. MVP vs. MVVM」という記事の中でうまく説明している：「たとえば古典的な MVP において View が IsChecked というプロパティをもっていて Presenter がそれを set しようとしているとすると、MMVM だったら ViewModel が IsChecked プロパティをもち、View がそれに同期しようとするだろう。」

MVP や MVVM にとっての望ましいゴールは、Presenter (または ViewModel) が簡単にユニットテストできることだ。というのみ、View の状態が必ず MVP では Presenter が呼び出すメソッドの中に含まれているし、MVVM では ViewlModel に set されるプロパティに含まれているから。

フロントエンドの開発を行うとき、このようなパターンは選択肢として完全にアリだ。ルーティングを行うレイヤーは制御を適切な Presenter (または ViewModel) に委ねることができ、今度は Presenter (または ViewModel) がブラウザの中で永続的な View に更新をかけたり反応したりすることができる。ちょっと修正すれば、これはサーバサイドでもうまく使えるようになる。理由としては単に Model と View がまったく連結していないからだ。 これによって一時的な View を Presenter (または ViewModel) が描画することができる。あとから説明するように、この微修正されたパターンは真に isomorphic となりうる。

モダンな JavaScript による実装

今まで述べてきたデザインパターンには、今日ではモダンな実装がたくさん存在している：

• Backbone.js
• Batman.js
• Angularjs
• JavascriptMVC
• Sammy

このようなフレームワークはふつうは 1 ページのアプリケーションを作るために使う (もっと伝統的に AJAX を使うことも可能だが) 。1 ページのアプリケーションの中におけるユーザ・インタラクションには 2 つのはっきりとした特徴がある。

• OnHashChange または pushState イベント：ブラウザの URL が変わったときに発生する。たとえば http://myapp.local/#/some-page に移動したとき
• DOM イベント：ユーザが現在の DOM ドキュメントに対して特定のインタラクションを行ったときに発生する。たとえば a タグをクリックしたとき

このようなライブラリで利用されているパターンやアーキテクチャについていくつか考えてみよう。興味のある向きは Peter Michaux の “MVC Architecture for Javascript Applications” という記事 を読んでみるといい。

Backbone

Backbone.js は今出ている中ではかなり人気のあるクライアントサイドの開発フレームワークだ。核心部分では伝統的な Model-View-Controller パターンが実装されている。しかし、もっと細かく調べてみると、上記で述べてきた伝統的な MVC パターンとはいくつか異なる点もある。

Figure 6: Backbone Model-View-Controller

上のダイアグラムでは OnHashChange イベントや Dom イベントの表す制御フローを分離して、Backbone の提供する別々のエントリーポイントを図示してみた。このニュアンスがうまく伝われば、Backbone と伝統的な MVC との間に 1 つの重要なちがいがあることがはっきりとするだろう：View が Model を操作するのだ。Backbone の Todo サンプルのソースコードを読んでみると、これが共通認識として受け入れられていることがはっきりと分かるだろう：

window.AppView = Backbone.View.extend({
  // ....

  //  
  // ToDoView が new されたら ToDo の Model のインスタンスに引き渡される
  //  
  addOne: function(todo) {
    var view = new TodoView({model: todo});
    this.$("#todo-list").append(view.render().el);
  }   

  // ....
}); 

window.TodoView = Backbone.View.extend({
  // ....

  //  
  // ここでは TodoView が Todo model の状態を更新している
  // これは伝統的な MVC からかけ離れており、View だけが Model への変更を
  // LISTEN することができる
  //  
  toggleDone: function() {
    this.model.toggle();
  }   

  // ....
});

伝統的な MVC パターンとは決別するという決断によって、規模の大きい Backbone アプリケーションはみんな同じような印象になるだろう：Controller のコードは少なく、モデルは密接に重い View と結びついている。このようなビジネスロジックの多く重い View は客観的に見れば Presenter と変わらないだろう。大規模な Backbone のコードベースでは、jQuery や zepto のようなDOM フレームワークでつなぎ合わされたたくさんのビューが存在すると思ったほうがいい。

伝統的な MVC パターンと決別することは何も悪くない。フロントエンドを開発するという意味では、View が Model を参照できると、アプリケーションから大量の bookkeeping なロジックを省くことができる。しかしながら、パターンは isomorphic ではないものとなってしまう。

Batman

Batman.js は JSConff 2011 でプレゼンされた新しい JavasScript フレームワークだ。Batman が内包する実体は Model, View, Controller なのだが、強力なデータバインディングエンジンと純粋な HTML View が存在するから、実際には Model-View-ViewModel の実装だということが分かる。

Figure 7: Batman Model-View-ViewModel

Batman であんまり作業をしたことがないから、自信を持って大規模な Batman アプリケーションのコードがどんな風になるかは分からない。Batman のドキュメントにはこう書かれていた：バインディングエンジンと軽量な View があるから、アプリケーション内のビジネスロジックは結局のところ Controller と Model にまたがることとなるだろう。

Backbone と同じように、Batman は伝統的な Model-View-ViewModel パターンと決別し、Model が直接 View とやりとりし、ViewModel (つまりは Controller) は View を直接操作しないようになっている。さらに、Model/View 間で互いに参照できるので、サーバサイドのパターンとしては容易に再利用することができない。しかしながら、もしも Composite パターンまたは Adapter パターンが Model のレイヤーに実装され、静的な View を描画したり、リアルタイムなリクエストに応答できるようになるならば、もっと簡単にサーバサイドのパターンに組み込むことができるだろう。

Real-time implications

ここ最近、開発者の間に広まるバズワードの中でもリアルタイムなウェブ・アプリケーションというのはとりわけ目立ちつづけている。Nodejitsu は今後予定されているポートランドの Keeping it Realtime カンファレンスの公式スポンサーである (チェックしてみてね！)。今まで見てきたパターンのうちのいくつかは十分にリアルタイムなサポート (WebSocket とか) をできるので見てみよう。

• Model-View-Controller (いける)：Model(s) がリアルタイムなイベントを監視し、適切に View を更新することができる。
• Model2 (ダメ)：一時的な View という考え方が Model2 には刷り込まれている。すなわち、Controller(s) は Model からのイベントを監視することができないのだ
• Model-View-Presenter (いける)：Model(s) はリアルタイムなイベントを監視することができるし、それを Presenter に伝えて適切に View を更新してもらうことができる
• Model-View-ViewModel (いける)：Model(s) はリアルタイムなイベントを監視することができるし、それを ViewModel に伝えて適切に View を更新してもらうことができる

このように MVC, MVP, MVVM は相性がよく、結果として Backbone.js や Batman.js はフロントエンドの開発におけるリアルタイムなフレームークとして役に立つことができる。だがサーバサイドでは必ずしもうまく行かない：伝統的な MVC, MVP, MVVM のパターンは View と Model が密接にかかわり合っているため、静的な View には役に立たないのだ。そこで Resource-View-Presenter の出番である。

Resource-View-Presenter を導入する

今まで見てきたように、MVC, MVP, MVVM パターンはみな、クライアントとサーバの両方ではうまく行かない。Resource-View-Presenter の重要なポイントは、どんなパターンも修正なしではクライアントとサーバの両方で完璧にうまく行くことはないだろう、と気づいたことだ。MVP・MVVM パターンを取り上げたときに指摘したように、MVP・MVVM では Model と View のレイヤーが分離されているため、パターンを真に isomorphic なものへと変更することが可能である。

Resource-View-Presenter が行った決断とは：

• Model と View を分離する
• クライアントとサーバのちがいを認識し、準備する
• View は軽く、Presenter と Resource を重く
• Presenter より Resource にビジネスロジックを書く
• 一時的な View (静的なサーバサイドの View) と永続的な View (DOM) の両方が使えるようにする
• ViewModel よりも Presenter にマークアップ (HTML) の純粋さを保持する
• 永続する Presenter と Model を前提とする

上記の決定はテキトーに見えるかもしれないが、それぞれにちゃんと目的がある：

• Model と Model を分離することで一時的な View と永続的な View の両方を扱うことができる
• View を軽くすることで weld や mustache のようなモダンなロジックの少ないテンプレートエンジンとうまくやっていける
• ViewModel の代わりに Presenter を採用することで、weld のようなデザイナーフレンドリーなテンプレートとうまくやっていける
• クライアント・サーバの両方で Presenter と Model が永続的であることを前提としているので、両サイドで Presenter 内のリアルタイム機能をカプセル化することができる

もっと考えを進めてみよう。クライアントサイドでは Resource-View-Presenter は伝統的な MVP パターンに似ている。Model を Resouce に改名したのは、ビジネスロジックが Presenter より Resource に書かれるべきだという前提のあることが大きい。

このため、RVP における Resource は Model2 の重い Model のほうに似ている。術語的には伝統的な MVP の Model に似ているように思われるのだが (??)。

RVP を実装する際に、そのロジックが Presenter に書かれるべきかどうかを判断するためには、2 段構えのリトマス試験紙が必要となる。どんな Presentation 中心のロジックでも 「軽い」View には重すぎるし、結局はグローバルなアプリケーションの状態を利用するビジネスロジックには View は重すぎるのだ。

Backbone や Batman のように、クライアントサイドにおける RVP 実装は OnHashChange / pushState によるルーティングと DOM イベントの両方をサポートするべきである。

Figure 8: Client-side Resource-View-Presenter

サーバサイドでも Resource-View-Presenter はほぼ同じだ。ただ一つ違うのは、View が一時的であり、Presenter に対して呼び出しを行ったり参照したりはしないということだ。実際、JSON ベースのウェブサービスに RVP を使うなら、View はほぼ存在しないと言ってよい。ただ JSON.stringify() を呼び出せばよいのだから。

Figure 9: Server-side Resource-View-Presenter

ぱっと見では、サーバサイドの RVP は Model2 MVC に似ているように見えるかもしれないが、Presenter と Model の永続性がリアルタイムなイベントをサポートすることができるので、そんなに似てはいないことがわかるだろう。RVP はこれを行うために、モデル上のイベントや変更を監視する、そのイベントや変更というのは裏側では Redis PubSub や CouchDB といったリアルタイムなデータソースの変更によって行われている。

リアルタイムのサポートは特に注目に値する。なぜなら、アプリケーションの開発者が裏側のネットワーク転送ではなく、ビジネスロジックに専念することができるからだ。ささいなことに見えるかもしれないが、Express や Socket.io の提供するパターン (やパターンの欠如) を見てみれば (Express と Socket.io はそれぞれかなり人気のあり node.js のフレームワークとリアルタイム IO のライブラリである)、それが重要であることがはっきりと分かるだろう。

Figure 10: Express and Socket.io

こんなことを書いたからって Express や Socket.io を攻撃しようとしているわけではなく、彼らはできることをきちんと明示しているし、できることに関してはかなりうまくやっている。彼らはもっと高レベルな問題を扱っているので、デザインパターンは問題にならないのだ。

結論

大規模なアプリケーションを書くのはむずかしい。そんな中で、クライアント-サーバをまたいでコンポーネントをカプセル化し再利用するのはさらにむずかしい。今まで述べた分析を読んでくれたあとだから明白になっていればいいなと思うのだが、あなたのアプリケーションの中で Resource-View-Presenter パターンを利用すれば、これを簡単にできる。

自分で実装する時間がないって？ 問題ないよ！ この記事を書くことができたのは、Nodejitsu が設立当初から行ってきたおびただしいオープンソース活動を行う上で、注意深く考え勤勉に努力してきたからだ。私たちの哲学はずっと変わらないままだ：最高のツールさえつくれば最高のシステムはついてくる。

きっとついてくると思っている。もうお気づきのこととは思うが、私たちは素晴らしいオープンソース製品のリリースを行おうとしており、そこでは Resource-View-Presenter パターンが実装されている予定だ。だから、もし何かフィードバックがあれば教えてほしい。そしてお見逃しなく、9/9 に行われるスウェーデン、ストックホルムの SWDC 2011 でこのリリースを発表する予定だ。