Application Controller

A centralized point for handling screen navigation and the flow of an application

画面の出し分けに関して複雑なロジックがある場合
- 一連の画面を特定の順番で出す
  - ウィザードとか
- 特定の条件下でのみ出す画面がある
- 前の入力によって異なる画面を出す
MVCのC -- Input Controllerが担っても良いが、下記の問題がある
- 複数のコードに同じロジックが散らばってしまう
画面フローのロジックをApplication Controllerとして切り出す
Application Controllerは、Input Controllerからの問い合わせをうけ、コンテキストに応じて次のものを返す
- 制御を移すべきモデル
- 返すべきビュー

How It Works

主な責務は2つ:
- どのドメインロジックに制御を移すかを決める
- どのビューを返すかを決める
2つのコレクションを用意して、クラスをルックアップする
- 内訳
  - ドメインコマンド
  - ビュー
- 「メタクラス」といえる
実装方法
- Command Pattern (Gang of Four)
  - Application Controllerの層のCommandオブジェクト
- クラス名・メソッド名文字列からリフレクション
  - Domain層
    - Transaction Script
    - Domain Objectのメソッド
- Server Page使用時は、その名前もルックアップに使える
Application ControllerはDomainとPresentationの中間層と捉える人が多い
- ここにおけるPresentationとは、webブラウザとかrich-clientとかPDAとかのこと
- メリット
  - 単体でテストできる
  - 複数のプレゼンテーションで再利用できる
Application Controllerの再利用に熱心になり過ぎぬよう
- プレゼンテーションが異なるということは、そもそも画面フローを変えたほうがUIとして良かったりする
- 開発コストは下がる
UIはステートマシン
- ステートマシンのフローをどう表す
  - メタデータ
    - コードで設定
    - コンフィグファイルで設定
Application Logic? Domain Logic?
- 線引きは曖昧
- 例: 保険のアプリケーションで、「喫煙」にチェックを入れた場合のみ、ある画面を表示する
  - この種のロジックが何箇所も出てこないならApplication Logicに入れちゃう
  - いっぱい出てくるならDomain Logicに移す

When to Use It

画面フローがシンプルなら価値は薄い
- 誰もが任意の画面に任意の順番でアクセスできる
フローを変更するとき、何箇所も直さなくてはならないようなら、適用価値があるきざし

勉強日記

チラ裏

PoEAA ch14 Application Controller

Application Controller

How It Works

When to Use It

Further Reading