11

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?

Philip Morton
  • 129,733
  • 38
  • 88
  • 97

4 Answers4

11

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.

Tom
  • 10,689
  • 4
  • 41
  • 50
10

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.

Pete
  • 229
  • 2
  • 3
  • 1
    "It is not possible to scale an application using a front controller." This seems evident just because of the way URI to classes have to be mapped, but how much better is raw PHP going to perform once data access and I/O has been considered? – Fred Wilson Jan 14 '11 at 21:49
  • 3
    @FredWilson My point about scaling is that if you use a front controller it means every request goes to a single entry point on all servers. If you have separate entry points for each part of an application, you can scale each piece individually eg. a mail application: you could allocate more servers to the read-email.php than send-email.php as people will generally read email more frequently than send. This cannot be acheived with a front controller, you would have to scale every eventuality together. – Pete Aug 27 '13 at 10:27
  • Is this info still relevant? Frameworks like Laravel, Zend Framework, Expressive, and many others seem to be using front controller pattern exclusively and direct-to-file routing is being called "outdated".. (https://stackoverflow.com/questions/48079853/what-are-these-routing-styles-called-in-a-web-application?noredirect=1#comment83133888_48079853) – Dennis Jan 03 '18 at 15:22
8

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
  • 11,780
  • 23
  • 72
  • 92
1

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.

ThorHalvor
  • 628
  • 5
  • 17