What are the advantages and disadvantages of using the Front Controller pattern?

Rephrasing the Wikipedia article on Front Controller:

In a sentence -- you use it to avoid duplication.

A little more detailed:

Front controller "provides a centralized entry point for handling requests." Let's assume the front controller for your web-app is index.php.

This script, index.php, would handle all tasks that are common to the whole application or the framework around, like session handling, caching, input filtering. Depending on the given input it would then instantiate further objects and call methods to handle the particular task.

The alternative to a front controller would be individual scripts like login.php and order.php that would each include the code or objects that are common to all tasks. This would need a repetition of the inclusion code in each script but might also leave more room for specific needs of a script.

Srikanth has a good answer. I'd like to elaborate on the alternative, though. Suppose you have this simple URL hierarchy:

/gallery
/blog
/admin/login
/admin/newpost

If this is implemented with Page Controllers (PHP, for example), both gallery.php and blog.php will need to include some common.php at the beginning (or nearby). However, both login.php and newpost.php may include admin-common.php, which itself pulls in 'common.php' and does '/admin/'-specific setup, like verifying the user is authenticated.

In general, if you have a hierarchy of URLs, it ends up looking a lot like object inheritance trees. Except instead of using language-level inheritance, you're inheriting the environment of whatever foo-common.php you include.

I can't imagine how a Front Controller is increasing testability, In the end, the exact same tests from an automated HTTP user-agent are required, regardless of implementation.

One major downside of Page Controllers is it does make your web application dependent upon its hosting environment. It also forces your developers to "see" the same structure as end users, but I consider that a good thing, considering the number of sites I see that have absolutely atrocious URLs.

One advantage of using a Front Controller is its testability. if you use TDD it is alot easier to test a controller than it is to request alot of different websites.

Added later: Tom: Thea reason i mean it is more testable is because you normally implement the webhandlers as class rather than server pages. and then you can do alot of tetst directly on the classes.

These are the reasons why i would never use a front controller.

• We have a perfectly good front controller its called a web browser.
• Each http request is unique and separate and should be treated as such.
• It is not possible to scale an application using a front controller.
• If you break a web application into small modules that are loosely coupled its easier to test the unit/module (your not testing the architecture as well as the controller for example) .
• Performance is better if you deal with a single request uniquely.

The front controller pattern simply doesn't fit IMHO. Build applications much the same way as UNIX, break a larger problem into small units that do one task, and do that task really well. Most of the frameworks are pushing developers to use front controllers and they are simply wrong.