MVW（Model-View-Whatever）パターンとは

MVCパターンには、MVC2、MVP、MVVMなど数多くの派生パターンがあります。
目的は同じなのに派生パターンがたくさんあるのは、それぞれのプラットフォーム固有の問題（フレームワークの違いや、サーバサイドかクライアントサイドかの違いなど）によってMV*の*の役割が異なるからです。

AngularJSは公式ページで"Superheroic JavaScript MVW Framework"と名乗っているので、またMVWなんていう新しいパターンが出てくるのかとゲンナリするかもしれません。
でもこれ、MVWという新しいパターンが提唱されているわけではないようです。

AngularJSの開発者はこんなことを言っていました。（引用元）

Having said, I'd rather see developers build kick-ass apps that are well-designed and follow separation of concerns, than see them waste time arguing about MV* nonsense. And for this reason, I hereby declare AngularJS to be MVW framework - Model-View-Whatever. Where Whatever stands for "whatever works for you".

「MV*について議論するのは時間の無駄だから、そんな暇があったらコードを書け。MV*の*の部分なんて"Whatever"でいいんだ。」という主張のようです。

言いたいことは分かりますが、だからといってWhateverなんて名前をつけたらControllerに何でもかんでも詰め込んでFat Controllerになってしまいそうです。
というわけで、時間の無駄だと言われてしまうのかもしれませんが、AngularJSのMVWパターンについて解説したいと思います。

Model・View・Whateverの役割分担

MV*パターン適用の目的はプレゼンテーションとドメインの分離です。
そこで、プレゼンテーション層とドメイン層に大きく分けた上で、それぞれの関係を図示してみました。

以降で各役割について解説します。

Model

Modelは他のMV*パターンと違いはありません。つまり、プレゼンテーションに関わらない部分すべてがModelになります。
アプリケーションにもよりますが、次のような役割を持つことが多いでしょう。

ビジネスロジック
データの入れ物
サーバーサイドとの通信
ローカルストレージ
etc.

他のフレームワークとの違いがあるとすれば、基本的にイベント通知の処理を実装する必要がない（例外はありますが）ところでしょうか。PureなJavaScriptのオブジェクトが使えるので実装が楽になりますね。

また、AngularJSのDI機能を利用してControllerとModelの関係を疎結合にすることができます。可能なところはどんどんService化するのがよさそうです。

View

Viewの役割は、レイアウトとプレゼンテーションロジックに分けることができます。

レイアウトを独自のDSLで記述したり、コードで記述するようなフレームワークもありますが、AngularJSはHTMLでレイアウトを記述します。
ただしAngularJSでは、Directiveという機能で新しいタグや要素を自由に追加することができるので、HTMLの形をしたDSLと言ってしまってもよいかもしれません。

DOMを操作するような複雑なプレゼンテーションロジックは、Directiveの中に閉じ込めてしまうので、HTMLのレイアウトは宣言的に記述することができ、可読性も高くなります。

Controller & Scope

Scopeの役割

Scopeは画面を描画するために必要な状態をストアする役割です。
MVVMパターンを知っている人にとっては、ViewModelと同じような役割を担っていると言えば分かりやすいでしょう。

クライアントMVCフレームワークを使わなかった場合、画面への描画内容と、描画するための状態（プレゼンテーションステート）は区別せず、DOMに両方の役割を持たせるのが一般的だと思います。
しかし、その方法では状態を管理することが難しく、ソースコードの可読性も低くなってしまいます。
そこで、AngularJSでは、DOMは画面の描画のためだけに使い、状態の保持はScopeで行うように役割分担をしています。
これにより、データの操作方法は明確になり、同一のデータを複数の場所に描画したり、異なる方法で描画するといったことが行い易くなっています。

Controllerの役割

ControllerはScopeをセットアップするための役割で、次のような仕事をします。

Scopeにサービスの呼び出しを結びつける
Scopeの保持するデータを初期化する
Modelのイベント通知をScopeに結びつける

Controllerにはビジネスロジックもプレゼンテーションロジックも書けるし、何かと太りがちな存在です。
ビジネスロジックはModelへ、プレゼンテーションロジックはDirectiveやFilterへ移譲し、できるだけControllerが太らないように気をつけなければなりません。

Controllerの分割

画面に要素を追加していくと、Scopeのメンバが増え、Controllerに渡すServiceの数も増えていきます。
もしそれが多すぎるのだとしたら、1つのControllerに役割を持たせすぎている可能性があります。

1画面につき1 Controllerにする必要はないので、画面内の要素ごとに分割したり、階層構造を作ったり、ng-repeat内の1要素ずつにControllerを割り当てたり、必要に応じて分割しましょう。

例えば、次のようにサイドバーと入力フォームと一覧表示部分と全体の親をそれぞれ別のControllerに分割したりします。

<div ng-controller="MainController">
  <div ng-controller="SideBarController">
    サイドバー
  </div>
  <div ng-controller="InputAreaController">
    入力フォーム
  </div>
  <div ng-controller="ListControlelr">
    <div ng-repeat="item in items">
      <my-directive data="item" ></my-directive>
    </div>
  </div>
</div>

コントローラを分離するとコントローラ間でデータ共有をする必要がでてきますが、手段はいくつか用意されています。

Angular JS で複数のコントローラ間でモデル（状態や値）を共有する方法 3 種類

Controllerを再利用しないのであれば親子関係を作ってやりとりし、そうでなければイベントでやりとりするのがおすすめです。
共通のサービスを使ったり$rootScopeを使ったりするのはグローバル変数と変わりないので、最終手段にするのがよいかと思います。

参考情報

本記事の内容は下記のスライドの考え方を参考にさせてもらっています。
XAML系プラットフォームの知識がなくても理解できる内容ですので、ぜひともあわせて読んでみてください。

GUIアーキテクチャパターンの基礎からMVVMパターンへ

おしまい

AngularJS Startup Advent Calendar 2013みごと完走ですね。
参加された皆様、特に発起人で13本もの記事を書かれた@matsuzanさん、お疲れ様でした！
読んでくれた皆様もありがとうございました！

始まる前は登録者も少なくて完走できるかどうか心配だったのですが杞憂でしたね。

この調子でAngularJSが盛り上がっていって欲しいものです。

AngularJSのMVWパターンを理解する