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

Question

I currently design all of my websites with a file for each page, then include common elements like the header, footer and so on. However, I've noticed that many frameworks and CMSs use the Front Controller pattern.

What are the advantages and disadvantages of using a Front Controller? Is the pattern simply used in frameworks and CMSs because it's not known which pages will exist in the final system?

Answer 1

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.

Answer 2

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.