Question

I’m not using any MVC framework and my application structure is rather simple…

actions/
  registration.php
classes/
views/
  header.php
  footer.php
  registration.php
index.php

actions/registration.php

<?php
$variable = htmlspecialchars($_GET['name'], ENT_QUOTES).", are you ok!?";
include("views/registration.php");
?>

views/registration.php

<?php
include("header.php");
echo $variable;
include("footer.php");
?>

index.php is entrance, so, calling index.php?action=registration will execute actions/registration.php

As you can see, this structure is rather simple and I think that almost every php developer has used this structure at some point. Do you have any advice regarding this application structure? How would you realize modules using this structure? Do you know any open source applications using this structure to explore?

Answer 1

The main problem I see is that you’re going to do a lot of repeating yourself.

If your actions and views are doing similar things, they’re going to maintain nearly duplicate code, which after 5 or 6 years can become a monstrous nightmare.

I have a project inherited from 2001 (back when an include flat-scripts idea was one of the more common ways of separating tasks in PHP) that has a similar structure. Now, after 9 years, here’s a summary:

vlad:~/workspace/myproj% find . -name '*.php' | wc -l
4357
vlad:~/workspace/myproj% du -hs
1.8G    .

You can imagine how fun it is to try and pick through this.

Even if you manage to successfully separate all of your actions into the appropriate flat files, you’re still losing out in that data isn’t compartmentalized properly, and therefore can’t be shared across the entire app in an organized way. Essentially, without using classes to manage your organization, and functions to control what actions can effect which data, you’re setting yourself up for a pile of spaghetti code once your app thrives and grows. In addition, you’re going to end up with an app where 1/3 of the lines of your code are include statements, none of which really indicate what’s going on directly. This can lead to confusing wild goose chases while hunting down bugs.

You may want to take a gander at http://wshell.wordpress.com/2009/10/12/encapsulation-in-php/, which appears to take a good look at why your organizational model may be a bad idea. There’s also the ever-fantastic developerWorks articles, one of which covers some good habits to get into as your project grows: http://www.ibm.com/developerworks/opensource/library/os-php-7oohabits/