ディスパッチャとコントローラ（アクション）の分離

[uzulla]

課題

各種コントローラの親クラスであるController::__construct()がディスパッチャやエグゼキュータの役目を担っており、自己呼び出しの構造となって見通しがあまりよくないように思える。

コントローラのいわゆるアクション的役割が状態を持っているのも難しい。

改善

コントローラ自体と、それを実行するもの（__constructで実行される一連の規約を行うもの）を分離したほうが見通しは良いように思える。

特にコントローラ自体にemit（echo）が内在しているのが不便。

• Twig化
• ディスパッチャ、エグゼキュータ、レンダラ、エミットの分離
• beforeFilterメソッドの整理(フィルタではなく、beforeAction化） 不要と思われるので、対応無し
• afterFilterメソッドの削除
• AppControllerクラスとControllerクラスの整理、統一
• リダイレクトの分離
• ルーターリファクタリング
• http メソッドの厳格化 各種URLにおける期待されるhttp methodの明示と厳格化 #279
• アクション（コントローラ）とモデル（ロジック）の分離

[uzulla]

管理画面については、テンプレートをTwigに切り替えると同時に修正を行っている。
ただし、Redirectについては修正していないため、完全ではない。

[uzulla]

#136 にてある程度改善。

残課題としては

• 「あるメソッドがアクションである」という明示性が不足しているのを改善したい（アクションと、アクション以外を分離）
  • 例：proxy的なクラスをつくる（単純に解決される）
  • 例：アクション以外を別のロジッククラスに切り出す（同時に$contoller->dataをRequestに移動するなどリファクタ）
  • これが解決すれば、一旦ルーター採用を見送る事ができる
• User、AdminControllerなどで継承で共通機能をもっているが、静的メソッドに切り出せるものはTrait化が検討できる（Userには必要だが、Adminには不要な機能などもあるので）
• ControllerとAppController間で責務に差がなく、統一して良いように思える（見通しが上がる）