私は現在、各ページのファイルを使用してすべての Web サイトをデザインし、ヘッダー、フッターなどの共通要素を含めています。しかし、多くのフレームワークと CMS が Front Controller パターンを使用していることに気付きました。
フロントコントローラーを使うメリットとデメリットは?最終的なシステムにどのページが存在するかがわからないため、パターンは単にフレームワークと CMS で使用されるだけですか?
私は現在、各ページのファイルを使用してすべての Web サイトをデザインし、ヘッダー、フッターなどの共通要素を含めています。しかし、多くのフレームワークと CMS が Front Controller パターンを使用していることに気付きました。
フロントコントローラーを使うメリットとデメリットは?最終的なシステムにどのページが存在するかがわからないため、パターンは単にフレームワークと CMS で使用されるだけですか?
スリカンスは良い答えを持っています。ただし、代替案について詳しく説明したいと思います。次の単純な URL 階層があるとします。
/ギャラリー /ブログ /管理者/ログイン /管理者/newpost
これがページ コントローラー (PHP など) で実装されている場合、 と の両方gallery.php
が最初 (または近く)blog.php
にいくつかを含める必要があります。common.php
ただし、 と の両方login.php
にnewpost.php
が含まれる場合がありadmin-common.php
、それ自体が 'common.php' を取り込み、ユーザーが認証されていることを確認するなどの '/admin/' 固有のセットアップを行います。
一般に、URL の階層がある場合、オブジェクトの継承ツリーのように見えます。foo-common.php
言語レベルの継承を使用する代わりに、含めるものの環境を継承していることを除いて。
Front Controller がどのようにテスト容易性を高めているか想像できません。最終的には、実装に関係なく、自動化された HTTP ユーザーエージェントからのまったく同じテストが必要になります。
ページ コントローラーの主な欠点の 1 つは、Web アプリケーションがそのホスティング環境に依存するようになることです。また、開発者はエンド ユーザーと同じ構造を「見る」必要がありますが、非常にひどい URL を持つサイトの数を考えると、これは良いことだと思います。
これらは私がフロントコントローラーを決して使用しない理由です。
フロントコントローラーのパターンは、IMHOに適合しません。UNIXとほぼ同じ方法でアプリケーションを構築し、大きな問題を1つのタスクを実行する小さなユニットに分割し、そのタスクを非常にうまく実行します。ほとんどのフレームワークは開発者にフロントコントローラーの使用を促しており、それらは単に間違っています。
フロントコントローラーに関するウィキペディアの記事を言い換えると、次のようになります。
文では -重複を避けるために使用します。
もう少し詳しく:
フロントコントローラーは、「リクエストを処理するための集中型エントリーポイントを提供します」。Web アプリのフロント コントローラーがindex.php
.
このスクリプト index.php は、セッション処理、キャッシング、入力フィルタリングなど、アプリケーション全体またはフレームワーク全体に共通するすべてのタスクを処理します。指定された入力に応じて、さらにオブジェクトをインスタンス化し、メソッドを呼び出して特定のタスクを処理します。
フロント コントローラーの代替手段は、login.php や order.php などの個別のスクリプトで、それぞれにすべてのタスクに共通のコードまたはオブジェクトが含まれます。これには、各スクリプトで包含コードを繰り返す必要がありますが、スクリプトの特定のニーズに対応する余地を残すこともできます。
フロント コントローラーを使用する利点の 1 つは、そのテスト容易性です。TDD を使用する場合は、さまざまな Web サイトを要求するよりも、コントローラーをテストする方がはるかに簡単です。
後で追加: トム: よりテストしやすい理由は、通常、サーバー ページではなくクラスとして webhandlers を実装するためです。そして、クラスで直接多くのテストを実行できます。