Application Controller は、一般的な MVC のコントローラー実装において、バラバラの Page Contorller のせいで起きる問題を解消するアイデアです。
Page Contorller はそれぞれが独立したオブジェクトで、プログラミングにおいてはこの分離された状態が、ほどよい凝集度を与えてくれます。しかし、Web は URL によるハイパーリンクで繋がっています。URL
(あるいはルーティング ID) という文字列の整合性が取れなくなると、アプリケーションは正しく機能しなくなります。また、Template View のファイルパスを指定するのも文字列です。これらの文字列プログラミングが苦痛になる最大の理由は、Page Contorller が本質的にバラバラの場所に存在するためです。
Application Controller は、アプリケーションにひとつ、あるいは一連の機能単位ごとにひとつ存在するオブジェクトです。Page Contorller 群が Application Controller を共有すると、そこに共通の知識を委譲できます。同じオブジェクトの中に全体の知識が集まると、あちこちに分散した URL や ID の文字列をメンテナンスする面倒が、一気に楽になります。
ハイパーリンクだけでなく、Service Layer の扱いに関する知識なんかも集約できるかもしれません。ID を文字列で指定するのは、ハイパーリンクやファイル名以外に、データベースのキーにも言えることなので。
Application Controller にとって、機能を直接持つのは負担になります。Page Contorller から何でもかんでも委譲された Application Controller は、依存が肥大化します。異なるページに異なる依存セットがあったものを、すべて抱えることになるからです。実際の仕事はそれぞれの Page Contorller で行うのが得策です。
Application Controller にできるだけ実機能を持たせないことは、単体テストにとっても有利にはたらきます。Page Contorller はその責務上、単体テストしにくい存在のひとつです。とくに、結果得られるものが HTML のビューであった場合、検証ロジックはテンプレートのレイアウトによって変化してしまいます。実動作する機能に関係することから、モックオブジェクトを設けるのにも苦労します。純粋なロジックによるテストで、しかもひとつのオブジェクトのテストだけで、ミスしやすい全体の整合性の多くをカバーできるのは、Application Controller を設けたときの大きなメリットになります。