MVC概論

MVCの重要性

  • アプリケーションのアーキテクチャ、実装手法
  • 設計と実装のノウハウ
  • 目標
    • 処理の分割・依存性整理
    • 変更通知の整理

ソフトウエアアーキテクチャ

  • BCE(Boundary, Control, Entity)
    • 分析・設計手法
    • →Webではそのまま設計に持ち込める
  • PAC(Presentation, Abstraction, Control)
    • アーキテクチャ、入れ子構造
    • GUIだけでなく、ソフトウエア設計一般に使えるパターン
  • MVC(Model, View, Controller)
    • デザインパターン
    • マウスとかイベントとか実装のノウハウ
  • その他いろいろ

WebアプリとGUIアプリの違い

  • GUIアプリケーションは複雑[絵]
    • データが変化する
    • 変化を通知する

Webアプリ

  • DBに永続化データがある
  • プログラムの寿命：一瞬
  • DBから取ってきたデータは基本的に変わらない
    • 不変(Immutable) → シンプルで扱いやすい

GUIアプリ

  • メモリ上にデータを保持
  • プログラムの寿命：長時間
  • メモリ上のデータを変更し続ける
    • データの変更が本質 → 矛盾無く更新し続ける必要がある

複雑性の制御とトレードオフ

  • 生産性・拡張性を上げる[絵]
  • 設計力が必要になる
    • 「不慣れな人」はメンテできなくなる
    • →むしろしてはいけない。
    • 「不慣れな人」がぐちゃぐちゃに作るよりはまし
    • →もともと出来ない。
  • スキルによってはリッチな動きをあきらめる

そのほかのクライアントサイドアプリ技術

  • 状態管理(tenjin.web/3)
  • 実装技術としてのOOP(tenjin.web/4)
  • ユーザーインタフェースデザイン(予定？)

MVCの詳細

  • Model
    • 管理すべきデータを表す（後述）
    • データの変更についての責任
    • 変更を通知
  • View
    • データを描画
    • 何個でも存在できる
  • Controller
    • GUIのイベントを元にModelを書き換えて更新
    • MV以外、VCは融合することが多い（議論）

MVCの心：設計方法

データ管理の一元化

  • 何がModelになりうるか？
  • 一カ所にまとめる
  • 誰がどういう責任を持つか
  • WebのMVCと似た話

データ変更の際の通知方法

  • ばらばらに伝えない
  • データの流れ、処理の流れを統一
    • 本来のMVCの大きな役目
    • データが刻一刻と変わっていく

HowTo

  • 扱うデータをGUIに関係なく本来あるべき形で保持する
  • データの入出力を限定する（勝手に中身を書き換えさせない）
  • モデルを使ってGUIを更新する

Point

  • 必ずViewが描画を制御する
  • 処理のメインストリートを意識する

実習

制限付きチェックボックス

  • アイスクリームトッピング
  • 仕様
    • 2個まで選択できる
    • 最新が残る

方針

  1. ビューを初期化しよう!
  2. モデルにロジックを書こう!
  3. ビューを更新しよう!
  4. イベントをハンドリングしよう!
  5. モデルを変更しよう!
  6. 最後に細かな調整を…
  7. ビューを追加し拡張しよう!

議論

サーバー通信

API設計

  • 手本はクラサバ設計
    • 例：VB（状態付きUI）とDB（データとロジック（ストアドプロシージャー））
    • メンテナンス性とパフォーマンス
    • データをローカルに持ちすぎない
    • 問い合わせも少なく
  • マスターのJOIN

初期化

  • HTMLに書くか、取りに行くか
    • レイアウト済みHTML （大変、最速、SEO有利）
    • レイアウト前HTML + 埋め込みデータ
    • レイアウト前HTML + データをAJAXで取りに行く （シンプル、遅い、SEO不利）

通信関係

  • エンコード
    • JSON:名前を短くする
    • JSONの配列に詰め込む, CSV, TSV
  • 通信頻度
    • キャッシュ制御の層を作る
  • ポーリング/comet
    • BlazeDSが手本かも

排他制御

  • heart beat
  • 楽観的ロック

実装テク

実装をやっているとよくあること

バリデーションをどこでやるか

  • GUI（ユーザーインタフェースのデザイン）で制御するのが基本
  • データ自身の最終的バリデーションはサーバー側の責任
  • モデルよりはコントローラーでリッチに行うべき

高速化

  • 最初は考えなくていい
  • 遅くならないイディオムを身に着ける
    • 普段から速度に関心を持つ
    • for・ループ・関数呼び出し / 文字列 / DOM / メモリ・GC
  • 描画通知の最適化
    • 描画通知を細かく制御
    • hintを使って再描画範囲を特定
  • setTimeoutで分散
    • クロージャーピットフォールに気をつける

Model, Controllerの肥大化

  • Service層、Facadeパターンの導入

View-Controllerの融合

  • 原因：VCのスコープが一致していることが多いため
  • 単純な分割は辛くなるだけ
    • 各CとVのスコープを調査して整理
  • 依存し合っているController同士でグループを作ってカプセル化
  • interfaceでCが必要とするスコープを切り出すなど

拡張性

  • 開発が進むとやりたいことがやりにくく感じる
    • 純粋にMVCの制限 → 耐えるべき
    • モデルやメインストリートの構造があってない
  • 思い切って大整理を行うことも必要
    • DRYをまとめるのではなくて、シンプル、楽になることが重要

ステートパターンとの連携

  • Controllerの中身を状態オブジェクトが担当
  • Viewの一部として状態オブジェクトが描画も行う

状態管理

  • (アプリケーション全体の状態) × (Modelの状態) の管理
  • Modelの状態によってボタンなどのGUIを書き換える
  • 条件行列のような感じ

必要なドキュメント

  • サーバーAPI、データ形式
  • モデル仕様、クラス図
  • 初期化、各イベント時のシーケンス図
  • 画面設計（完成画面をどのように組み立てているか）
changed October 9, 2009