In a multipurpose website (user system, lots of database operations on different tables, schedule creators, …) should all PHP request be centralized to one app?

For example, my current set up is like this:

  1. User related requests go to users.php
  2. Managing a specific MySQL table goes to ../tables/thatTableName.php
  3. Managing a schedule goes to schedule.php
  4. etc.

Each of these files has their own way to process incoming requests ($_POST and $_GET).

Another approach is to centralize is this into something like a main.php which would process all requests, create necessary classes when required (like a user), and co-ordinate all tasks.

What are the benefits and drawbacks of either approach?

3 Answers 3


Most major PHP applications that were created in, say, the past 10 years do use some manner of a Front Controller to handle all requests. That is, requests are routed through a single handler that then responds (usually following some variation of an MVC pattern).

To create user friendly URLs, such as "/user", redirects are set up in the site's .htaccess file or directly in the server configuration. These map the requested path to the correct sets of parameters for the Front Controller.

Whether that's 'best' or not... that's really up to you. But the concept of "one page = one PHP file" and using included() headers to handle common functionality is decidedly old school PHP, and not something most modern developers follow.

  • “is decidedly old school PHP”: indeed, but why? I mean, if it's just fashion, it's one thing. If there are serious performance hits or an actual proof that maintenance becomes a nightmare, or some other good reason, it's a very different story. Mar 30, 2016 at 7:08
  • 1
    @MainMa It's about maintainability. If you spread your source code across 30 files and you want to change something that touches the core, you suddenly need to do it in 30 files instead of one. The files are bound to diverge as time goes which makes it that more difficult to then streamline when you need to change some core functionality. Also one file per route won't work for dynamically generated pages, unless you add routing. In which case you could've had it from the very beginning.
    – Maurycy
    Mar 30, 2016 at 8:57
  • @Maurycy: if I want to change the core, I'll change the corresponding class which, through the chain of includes finds its way into the 30 PHP files which are actually serving the requests. I partially agree with the second part of your comment, although a reverse proxy can do a great job of transforming the requests when code moved from one PHP file to another. Mar 30, 2016 at 9:43
  • 1
    @MainMa if you're super disciplined to always keep every common functionality in shared included files then of course it'll work almost as well (it's probably going to be harder to unit test). But! My experience says that every project more complex than a calculator sooner or later falls victim to just putting route-specific logic directly in the file which then turns into an unmanageable and untestable mess especially if you add more devs to the mix. I suggest you to take a look at open source forum and wiki software which did things that way and see what problems they faced.
    – Maurycy
    Mar 30, 2016 at 10:57
  • @MainMa its hardly a fashion issue. When I switched away from the "one page = one PHP script" paradigm back in early PHP4 days, doing so was decidedly unfashionable. Its all about, as Maurycy says, maintainability. Mar 30, 2016 at 20:30

In a www facing application make sure everything goes through one door.

If you're building a single application you should have a single point of entry. If you're building bunch of handy utilities that happen to be accessible via Apache or some other app server then build the bunch of utilities as single scripts...

The funny thing is that once you have several utilities something common emerges and it quickly becomes an app, ie I need to allow these parts to OPS and these parts to someone else ie Basic Auth and from there it snowballs to a full blown App or worse a CMS.


The benefit of having a different file per endpoint is simplicity during initial programming. The downside of such an approach, as compared to a front controller, is complexity while maintaining.

Each of those files will need to parse its input, perform CSRF checks, and generate output. This code is duplicated tens, hundreds, possible thousands of time. Duplicate code is hard to maintain, because any change requires modifying many files. To make matters worse, this is almost impossible to unit test or reuse in different contexts, because the logic inside the files is directly tied to the HTTP input and output. Also, if you ever decide you need to do a deep refactoring, all of your URL's are changing as well, since there is no separation between the structure of the business logic and the layout of the URL space.

In contrast, a front controller can isolate business logic (in the controller methods) from the mechanics of input parsing and output building. It allows for a central place to handle common logic like session handling and CSRF checks. It also allows for decoupling URL from business logic, enabling deep refactoring without user-visible changes. Unit testing the isolated business logic becomes much easier, as well as reuse in other contexts (e.g. in background job queues). There are very few downsides. The code becomes a little harder to understand until you figure out how URL's are mapped to business logic (which will be a standard way for that framework), and the added layer of abstraction can have some minor performance consequences.

The strong benefits of a front controller over the one-file-per-endpoint approach is why all modern frameworks use this approach.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.