読者です 読者をやめる 読者になる 読者になる

理系学生日記

おまえはいつまで学生気分なのか

忍者TOOLS

PoEAA: Model View Controller

poeaa

今日からは、Web Presentation Pattern の章にはいります。 最初が Model View Controller なんですが、おそらく開発者の誰もが聞いたことがあるパターンです。

Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler))

Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series (Fowler))

Model View Controller は、以下の 3 つの役割を定義するところから始まります。

  1. Model: ドメインに関する情報を表現するオブジェクト
  2. View: UI 上のモデルの表現
  3. Controller: ユーザの入力を受けて、モデルを操作し、View を適切に更新する役割。

この 3 つの役割により、UI は 2 つの分離が起こります。1 つは「モデル」からの「表現」の分離、もう 1 つは「表現」からの「Controller」の分離です。特に前者の分離の重要性は著しく高く、これは以下のような理由に依ります。

  1. そもそもモデルと表現では、開発者に求められるスキルセットが全く異なる
  2. 同じモデルに対する、複数の表現が必要となるケースが多々ある。リッチクライアントやブラウザ、API や CLI インタフェースなど。
  3. 表現を排除すれば、モデルに対するテストが容易にある

逆に興味深かったのが、公社の「表現」と「Controller」の分離の重要性は低いとされていることです。 例として挙げられているのは、View の Editable/Non-Editable (Readonly) の振舞いをどう実装する場合が多いか、ということですが、これを分離しようと思うと、Editable な Controller と Non-Editable な Controller を配置することになると説明されています(たぶん)。 一方で、実際としてはそんなことはせず、1 つの Controller で Editable/Non-Editable の両方の View の振舞いを実現するはずだし、表現と Controller の分離は必要になったときにすれば良いよって温度感でした。

というわけで、これからようやくおもしろい章に入りそうです (DB あたりは長かったので飽きてきていた)。