@fujixfujiko

« 私の中のJavaScriptの進化 | メイン  | JavaScriptのパフォーマンスを上げる13の方法 »

エラーが発生しました。もう1度ご確認ください。
コメントの画像認証を入力してください。

MVCの時代は終わった。MOVEを使い始めましょう。

こんぬつは(o・ω・o)

ステートフルJavaScript』という本を最近買いました。
原題は『JavaScript Web Application』というらしいんですが、まんまとタイトルに惹かれちゃいましたよ。
メインはMVCの話っぽいんですが、JavaScriptMVCとかWebSocketとか、気になっていたものがいろいろ紹介されているみたいなので、今度の通勤のお供はこれにします。


で、今日のブログのネタはこれです。

『MVCの時代は終わった。MOVEを使い始めましょう。』

MVC is dead, it's time to MOVE on.
http://cirw.in/blog/time-to-move-on

今MVCについての本を読んでるところなんですが、何か?(笑)
てかこのサイト、レスポンシブデザインなんですね。
会社で見たときは論文みたいに2カラム構成になっていましたが、家のパソコンで見たら1列表示だったので、別サイトかと思っちゃいました。


はてブにも挙がっていたので、とりあえず訳してみました。
誰かのためになればいいな。

『MVCの時代は終わった。MOVEを使い始めましょう。』


MVCは素晴らしいアイディアで、次のものを含んでいます。状態の集まりであるModel(モデル)、UIの集まりであるView(ビュー)、そしてController(コントローラ)は...

何の集まりでしょう?

こう考えたのは私が初めてではないはずです。しかし、MVCのこの問題によって、人は余計なコードまでをControllerに詰め込んでしまうことになります。なぜなら、他に入れる場所が分からないからです。

これを解消するために、私はある新しいパターンを使っています。それは、MOVEModels、Operations、Views、Events)です。


概要



詳細は後で説明しますが、まずはこのダイアグラムで、MOVEアプリケーションの基本構成を見てみてください。
  • Modelは、アプリケーションが知っていることを全てカプセル化します。
  • Operationは、アプリケーションがやることを全てカプセル化します。
  • Viewは、アプリケーションとユーザの仲立ちをします。
  • Eventは、これらのコンポーネントを安全に連結させるために使用されます。
スパゲッティコードを避けるために、次のことも知っておいてください。これらは、各タイプのオブジェクトが、それぞれ何をしていいかという提案です。これを、先ほどのダイアグラムでは、矢印を使って描画しました。例えばViewは、Modelによって発せられたイベントを聞くことができます。OperationはModelを変更できますが、ModelはViewもOperationも参照できません。


Model(モデル)

典型的なモデルとして、「user」オブジェクトがあります。少なくともメールアドレスと、あとは名前と電話暗号なんかを持っていると思います。

MOVEアプリケーションでは、Modelは知識のみをラップします。つまり、ゲッター(訳注:データを取得する関数)やセッター(訳注:データを設定する関数)に加え、「○○はそのユーザのパスワードであるか?」のようなチェックをする関数を含むかもしれません。しかし、それらをデータベースに保存したり、外部APIへアップロードするような関数は含みません。それは、Operationの仕事です。


Operation(オペレーション)

色々なアプリケーションで共通のオペレーションといえば、ユーザログインがあります。これは実は、2つのサブオペレーションが一緒になっています。1つ目は、ユーザからメールアドレスとパスワードを受け取るオペレーション、2つ目は、データベースから「user」モデルを読み込み、パスワードが一致するかどうか調べるオペレーションです。

Operationは、MOVEの世界の実行者です。モデルを変更し、適切なときに適切なViewを表示し、そして、ユーザインタラクションから発生したイベントに返答することに対する責任を負っています。上手に役割分担されたアプリケーションでは、各サブオペレーションは、親から独立に走査されます。これが、ダイアグラム上でEventが親に向かい、Changeが子に向かっている理由です。

この方法でOperationを使うことで面白いのは、アプリケーション全体が、プログラムがブートするタイミングで開始するオペレーションとして扱われることです。現在存在しているサブオペレーションとは平行に、必要な数だけサブオペレーションが生成され、すべて完了するとプログラムは終了されます。


View(ビュー)

ログイン画面はViewです。Viewは、ユーザに少数のテキストボックスを表示することに対して責任を負っています。ユーザが「ログイン」ボタンを押したとき、Viewは「loginAttempt」イベントを発生させます(訳注:attempt≒try)。このイベントには、ユーザが入力したusernameとpasswordが含まれています。

ユーザが見たり操作したりことができるすべてのものは、Viewによって提供されるべきです。それらは、分かりやすい方法でアプリケーションの状態を表示するだけでなく、意味のあるイベントへのユーザインタラクションの流れを簡略化します。重要なのは、Viewはモデルを直接変更したりしません。単にイベントをOperationに渡し、Modelが発生するイベントを監視しながら、変更を待つだけです。


Events(イベント)

「loginAttempt」イベントは、ユーザがログインをクリックしたときにViewが発行します。そして、ログインオペレーションが完了すると、「currentUser」モデルが、自身が変更されたことをアプリケーションに伝えるためのイベントを発生させます。

イベントの監視とは、MOVE(またはMVC)に対し、どのViewを更新しているのかをModelが直接気にしなくていいように、ModelにViewの更新をさせる必要があるという、コントロールの反転を与えることです。これは、コンポーネント同士を、お互い干渉せずに連結できるようにするための、とても強力な抽象化の技術です。


なぜ今MOVEを使うのか

誤解しないで欲しいのですが、MVCが悪いと主張しているわけではありません。ここ数十年の間、本当にMVCは、大きなアプリケーションを構成するための、すばらしく効率的な方法でした。しかし、MVCが発明されてから、新しいプログラミング技術がいくつか広まりました。クロージャ(や無名ブロック)が無いとイベントのバインドはとても退屈ですし、deferrable(deferredやpromiseとも言う)が無いと、個々のオペレーションをオブジェクトとして独自に扱うというアイディアは、全然意味をなさなくなります。

繰り返しますが、MVCはすばらしいものです。ただ、数十年前の技術でデザインされているんです。MOVEは、今ある新しいツールをもっと良く活用するための、最新版という感じです。

追伸:この方法は、私だけが考え始めたものではありません。MOVEのアイディアが気に入ったならば、objectifyinteractionsをチェックしてみるといいと思います。すでにあるMVCアプリケーションに、MOVEのいいところを追加しようと試みています。他にもリンクを知っていたら教えてください。ここで紹介します!