one script to server all architecture, good or bad?

[wincen]

I was wondering if using one script that servers all is a good architecture for a php application?  If it is used in a site which grows to have lots of traffic will it still hold up?  If not, what are some other suggestions?

 

this code i think is basically a front controller that calls other controllers depending on what the user sends to the server.  $driver is basically the controller for whatever page is to be called.

 

file: index.php

<?php

if (!in_array ($_GET['page'], array('index', 'contact', 'about')))
{
    $page = 'index';
} else {
    $page = $_GET['page'];
}

$driver = false;

switch ($page)
{
    case 'contact':
        include 'classes\contact.php';
        $driver = new Contact();
        break;
    case 'about':
        include 'classes\about.php';
        $driver = new About()
        break;
    case 'index':
    default:
        include 'classes\main.php';
        $driver = new Mainpage();
        break;
}

if ($driver)
{
    $driver->Display();
} else {
    die ('some type of 404 message');
}

?>

 

 

suggestions, improvements, criticisms are all welcome.  i'm trying to build my first OO php websites and would like to know if i'm on the right track.  plus i haven't used php in a few years so i might be out of touch with new features and developments.

 

i have read a few articles that state having a front controller, or one script to server all is bad because that's what apache already does... so this may be bad for performance.

 

 

 

[Buyocat]

Using a front controller to set some universal data and then call a page controller to handle the page specific dealings is a good way to handle things.  I personally think that controllers are not good objects in the sense that they are tightly coupled with the view/model and hard to test.  That said they're a good place to start to expose yourself to some OO challenges and as a way to reuse some common behavior.

 

Looking at you code I can tell you right away that you'll want to make some changes.  Really, the worst of it is the switch statement.  You should be able to load a page dynamically through reflection.  If you're using PHP 5 and haven't used reflection before it's worth checking out.  I can also provide you with a facade I've written for the reflection API which allows you to create a new instance of a class and invoke a method.  The reason you want to lose the switch is because you'll end up having to add a new case for every page, which is a pain.  Instead you should use reflection and have something that looks roughly like so:

 

(note this is pseudo code)

$page = $_GET["page"];
$action = $_GET["action"];

try {
    $control = Reflection::getInstance($page, array($args));
    Reflection::invoke($control, $action, array($args));
} catch (Exception $e) {
    $error->handle($e);
}

 

[448191]

i have read a few articles that state having a front controller, or one script to server all is bad because that's what apache already does... so this may be bad for performance.

 

Maybe, if you have an incredibly busy site on a single server, you will run into file system concurrency factors negatively influencing performance. I think you'll be forced on multiple servers before that happens though.

 

I would like to read the articles you're talking about though.

[Buyocat]

I believe this is the article, or at least I had read it a while ago and it sounds familiar.  The fellow makes the point that Apache is already handing a lot of the controller's responsibility by taking in all the incoming data (post and get) and identifying the context (url).

 

http://www.phppatterns.com/docs/design/the_front_controller_and_php

[Mastodont]

wincen,

 

how and where do you want handle input from user ($_POST)?

[trq]

You should be able to load a page dynamically through reflection.

 

Even without reflection you can dynamically instantiate and execute a method of a certain class pretty simply without any need for a switch.

 

<?php

  if (isset($_GET['page'])) {
    if (file_exists("classes/{$_GET['page']}.class.php")) {
      include_once "classes/{$_GET['page']}.class.php";
      $obj = new $_GET['page']();
      if (isset($_GET['action']) && method_exists($_GET['page'],$_GET['action'])) {
        $obj->$_GET['action']();
      }
    }
  }

?>

[wincen]

wow, thorpe and buyocat, those are some very nice solutions.  sweet.

 

i don't remember every article that stated using a front controller in php is bad, but one of them was the on posted by buyocat. 

 

There was also Ramus Lerdorf no-framework PHP MVC framework http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC-framework.html in which he states

 

Just make sure you avoid the temptation of creating a single monolithic controller. A web application by its very nature is a series of small discrete requests. If you send all of your requests through a single controller on a single machine you have just defeated this very important architecture. Discreteness gives you scalability and modularity. You can break large problems up into a series of very small and modular solutions and you can deploy these across as many servers as you like

 

 

He brings this point up again in one of his replys to user comments:

I think you guys are missing the point. It isn't about OOP vs. Procedural. I could just as easily have written the controller code as a series of objects. The important point is not the style of the code, the important point is that you don't have a single monolithic controller that becomes your bottleneck and forces all your controller logic into one place because it turns what is supposed to be a discrete and modular architecture into a monolithic one.

 

I've been taught that implementing design patterns like front controller, MVC, and factory are very good practices when creating websites; but when the creator of php is saying that the front controller is a bottleneck it makes me question what i've been taught.

 

[roopurt18]

This is one of those things you must play by ear.

 

I don't think most sites receive enough traffic for a single controller to become a bottleneck.

 

Also, there are some steps you must take every time someone visits a site in the page so they tend to be in a centralized location.

 

Keep in mind that a front controller should be short and to the point, don't allow any unnecessary processing in a site's entry point.

 

Also, you should only direct traffic that needs to go through the controller and let the web server handle everything else.  For example, there's no point to send a site's images through a controller.

 

Hope that helps some.

[448191]

I don't think most sites receive enough traffic for a single controller to become a bottleneck.

 

I agree. At the point that it does, you'll need multiple application servers, because you will at the very least be close to running out of computing power. When you use distributed computing, a gateway can decide which requests goes to which server, each with their own single point of entry.

 

An interesting read on this subject is PoEEA's "Distribution Strategies" chapter.

[wincen]

An interesting read on this subject is PoEEA's "Distribution Strategies" chapter.

 

what is PoEEA?  and where can i get it to read that chapter?

[448191]

Patterns of Enterprise Application Architecture -- by Martin Fowler.

 

It's the second most influential Design Pattern catalog, but the narrative chapters also provide some interesting thoughts on concurrency issues and distributed computing.