PoEAA ch14 Front Controller
Front Controller
A controller that handles all requests for a Web site.
- 複雑なWebサイトでは、リクエスト処理時に似たようなことをたくさんする
- セキュリティ
- i18n
- 特定ユーザ向けのビューの返却
- Front Controllerがこれらを一手に引き受ける
- 似たロジックをあちこちに散らかさない
- 実行時にふるまいを変えることもできる
- Decorator Pattern (Gang of Four)
How It Works
- 2つのパーツからなる
- Web handler
- Command Hierarchy
Web handler
- 責務
- WebサーバーからPOSTやGETのリクエストを受け取る
- URLから情報を抽出する
- どのアクションを行うか決定し、制御を移す
- 【補】Laravelでいうと、
Http\Kernel
がこれにあたる - 実装
- ほとんどの場合classとして実装される
- server pageとしては実装されない
- ほとんどの場合classとして実装される
- 静的 vs 動的
- 静的のメリット
- explicit interface
- URLごとに柔軟な処理ができる
- 動的のメリット
- Command追加時にWeb Handler変更の必要がない
- 静的のメリット
- 動的の場合はURLとCommandを紐付けるコンフィグファイルを設けることがある
- 【補】Laravelでいうと
routes/web.php
- 【補】Laravelでいうと
- [Alur et al.]のIntercepting Filter Patternと組み合わせると有用
- Decorator Patternでfilter chainを実現
- 認証とか
- i18nとか
- 【補】Laravelでいうと
ミドルウェア
- Decorator Patternでfilter chainを実現
Controller Hierarchy
- 【補】LaravelでいうとControllerクラス群
- Laravelの
Controller
はMVC的なControllerを構成する一部にすぎない
- Laravelの
- 責務
- 制御を移すドメインロジックを決める
- 返却するビューを決める
When to Use It
- Page Controllerパターンよりも込み入っている
- ということはメリットが有る
- Webサーバの設定が楽
- ただ1つのFront Controllerにリクエストを渡せば良い
- スレッドセーフ
- リクエストごとに1つのCommandクラスを用意するため
- ただし、Commandが制御を移すDoman Modelはこの限りではない
- コード重複の排除
- ただし、Page ControllerでもLayer Supertypeを適用すれば回避可能
- 【所感】「機能の共通化のための継承」はやめたほうがいいと思うけど…
- ただし、Page ControllerでもLayer Supertypeを適用すれば回避可能
- Decorator Pattern (Gang of Four)で実行時に振る舞いを変えられる
- Webサーバの設定が楽
Further Reading
Example
- 略