これまでの「MVC」とBackbone.jsの関係について少し理解した。

Backbone.jsのFAQに、記事タイトルの件について勉強になる内容が書かれていました。

せっかくなので、読んで理解したことを僕なりにまとめてみようと思います。

Backbone.jsの「View」はこれまでのMVCで言う「Controller」

MVCパターンにはいくつかの実装が存在しますが、それらを比較すると、「Controller」の定義が違ったものになっていることが多いみたい。

Backbone.jsでは、「View」が、一般的に言う「Controller」の役割、つまり、UIで発生したイベントを処理して、HTMLテンプレートと共に結果をフィードバックする役割を担っています。

Backbone.jsがどうしてわざわざこれを「View」と呼んでいるというと、

We call it a View because it represents a logical chunk of UI, responsible for the contents of a single DOM element.

How does Backbone relate to “traditional” MVC?

と書いてあります。僕なりに翻訳すると

「Backbone.jsのViewは、あるDOM要素の内容をつかさどる、論理的なUIの塊を表現しているから」

という感じでしょうか。ちょっとわかりづらいですが、一般的な「MVC」で言うところの、「Controller」と「View」の結びつきが強いということなのだと思います。

Backbone.jsのMVC構造をこれまでのMVC(Rails)と比較

Backbone.jsのMVC構造/構成要素を、Railsのような一般的なサーバサイドMVCに当てはめて説明すると以下のようになるようです。(これも僕なりの翻訳)

  • Backbone.Model: RailsのModelからクラスメソッドを除いたようなもの。ビジネスロジックにおける一行のデータを表現/ラップしたもの。
  • Backbone.Collection: 複数のモデルで構成されるグループ。複数のデータのソートやフィルタリングのロジックはここに含まれる。
  • Backbone.Router: Railsにおける「routes.rb」とControllerのアクションに対応するもの。URLと機能(関数)をマッピングする役割がある。
  • Backbone.View: 再利用可能なUIの部品。大抵の場合はModelの関連付けられて用いられる。
  • Client-side Templates: Railsにおける「.html.erb」(ビュー/テンプレート)に対応。部分的なHTMLの描画を担当する。

これはわかりやすいですね。

Backbone.jsのViewは「大抵の場合はModelの関連付けられて用いられる」ということからも、これまでのMVCにおける「Controller」の役割を持っていることがわかります。

まとめ

クライアントサイドの処理は、UIを操作したことで発生したイベントの処理と、その結果をUIにフィードバックする処理で構成されます。

その特性に対応するために、これまでのMVCと比べて「Controller」が「View」との結びつきを強める方向に進んでいった結果、呼び方までも「View」に変わってしまった。その結果がBackbone.jsなんだと僕は理解しました。

みなさんはどのように理解していますか?ご意見、ご指摘等ありましたらいただけると嬉しいです。

それでは。