きしだのはてな このページをアンテナに追加 RSSフィード

2012-07-04(水) [翻訳]MVCは死んだ。MOVEするときがきた

[]MVCは死んだ。MOVEするときがきた 10:41 MVCは死んだ。MOVEするときがきたを含むブックマーク

Conrad Irwinさんの「MVC is dead, it's time to MOVE on.」を訳してみました。

MVC is dead, it’s time to MOVE on.


この訳文も原文のライセンスを引き継いでCC-BY-3.0ライセンスで利用可能とします。


追記13:58 すでに訳してた方がいました。MVCの時代は終わった。MOVEを使い始めましょう。 - ふじこのプログラミング奮闘記


MVCは死んだ。MOVEするときがきた

MVCはすばらしいアイデアだ。モデルを持ち、モデルは内部に少しの状態をもつ。ビューは内部に少しのUIをもつ。そして、コントローラは内部に少しの・・・


何を持つ?


私は確かにこのことに気づいた最初の人物ではない。しかし示されたようなMVCの問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいかわからないからだ。

この問題を解決するために、私は「MOVE: モデル(M),オペレーション(O),ビュー(V),イベント(E)」という新しいパターンを使っている。


概要

Architecture of a MOVE app

詳細な定義はもう少しあとにしよう。この図はMOVEアプリケーションの基本的な構造を表している。

  • モデルはアプリケーションが知っていることを全てカプセル化する。
  • オペレーションはアプリケーションが行うことを全てカプセル化する。
  • ビューはアプリケーションとユーザーを仲立ちする。
  • イベントはこれら全てのコンポーネントを一緒に安全に結びつける。

スパゲティコードを避けるために、それぞれの種類のオブジェクトが何を許されるか、お勧めがあるということも記しておこう。これらは上図で矢印として示しておいた。例えば、ビューはモデルから発せられたイベントを待ち受けることができる。そして、オペレーションはモデルを変更することが許されている。しかしモデルはビューもオペレーションも参照しない。


モデル

典型的なモデルは「ユーザー」オブジェクトである。最低限はメールアドレスと、恐らく名前や電話番号を持つ。


MOVEアプリケーションでは、モデルは知識をラップするだけである。ということは、ゲッターやセッターに加えて、「これはこのユーザーのパスワードか」をチェックする関数を含んでもよい。しかし、データベースにユーザー情報を保存したり、外部APIにアップロードしたりする関数は含まない。それらはオペレーションの仕事である。


オペレーション

アプリケーション間で共通のオペレーションといえば、ユーザーのログインである。これは実際は二つのサブオペレーションを組み合わせたものだ。最初の1つはユーザーからメールアドレスとパスワードを得る。2番目は「ユーザー」モデルをデータベースから読み込んで、パスワードが正しいかチェックする。


オペレーションは、MOVEの世界での実行者である。それらは、モデルの変更を行い、正しいビューを正しいタイミングで表示し、そして、ユーザーの操作をきっかけにしたイベントに応答する役割を持つ。よく因子分解されたアプリケーションでは、それぞれのサブオペレーションはその親から独立して動かすことができる。これが上の図で、イベントの向きが上向きで、変更が下向きになっている理由である。


オペレーションをこのような方法で使うといいことは、アプリケーション全体で、プログラムがブートして開始するときと同じようにオペレーションを扱うことができることである。必要なだけ多くのサブオペレーションを生成して、それぞれの同時に存在するサブオペレーションを並列に動かし、そしてすべてが完了したときにプログラムが終わる。


ビュー

ログイン画面はいくつかのテキストボックスをユーザーに表示する役割を持ったビューである。ユーザーが「ログイン」ボタンをクリックすると、ビューはユーザーが入力したユーザー名とパスワードを持った「loginAttempt」イベントを引き起こす。


ユーザーが見るもの、操作するもの全ては、ビューによって制御される。アプリケーションの状態をわかりやすく表示するだけではなく、やってくるユーザーの操作のストリームを、意味のあるイベントに簡潔化する。大事なのは、ビューはモデルを直接変更せず、単純にオペレーションへのイベントを発する。そして、モデルから発せられるイベントを受けつけて変更を待つ。


イベント

「loginAttempt」イベントはユーザーが「ログイン」ボタンを押したときにビューから発せられる。加えて、ログインオペレーションが完了したときに、「currentUser」モデルはそれが変更されたことをアプリケーションに伝えるイベントを発する。


イベントの受けつけは、IoC、制御の逆転をMOVE(とMVC)に与え、モデルに直接どのビューを更新するか気づかせることなしに、そのモデルにビューの更新を可能にする。これは、強力な抽象化技術で、互いに妨げることなくコンポーネントを結び合わせる。


なぜ今?

MVCが悪いと暗示しているように誤解してほしくはない。それは確かに、大きなアプリケーションを組み立てるための、信じられないほど成功する方法であった。この数十年は。とはいえそれが発案されてから、新しいプログラミング技術が一般的になってきた。クロージャー(または匿名ブロック)なしでは、イベントの構築は非常に退屈である。そして、遅延制約(遅延評価やプロミスとして知られている)なしでは、個々のオペレーションをそれぞれのオブジェクトとして正しく扱うこのアイデアは、多くの意味をもたない。


繰り返すが、MVCは素晴らしい。しかし10年古い技術によって設計されている。MOVEは新しく我々が手に入れた道具を使って更新しただけだ。


P.S.

私はただ一人このように考え始めたわけではない。MOVEのアイデアを気に入ったなら、objectifyinteractionsをチェックしよう。これらはすでに存在するMVCアプリケーションにMOVEの利点を追加することを試みている。ここに追加するべきリンクを知っていたら教えてほしい

Conrad IrwinConrad Irwin 2012/07/04 11:23 Hi,

Thank you very much for translating this!

Conrad

rokugenrokugen 2012/07/04 13:06 因子分解はリファクタリングですか?

rokugenrokugen 2012/07/04 13:07 あ、すみません。自分で原文読めば良かったですね…自己解決しました。

nowokaynowokay 2012/07/04 15:53 factorですね。分解だけでなく、要素が最低限ってニュアンスも必要かなと思って「因子分解」としました。

tockritockri 2012/07/05 18:09 なにがMでVでCなのかを最適に決めたい、という手法としてイベントとオペレーションっていう考え方は一つ有効かもしれないですね。でも別にMVC死んでねえ…

nowokaynowokay 2012/07/05 18:33 MOVEがいいとしても、MVC死んでないね、たしかに