I need your advice about php application structure (not MVC, but something simplier)

Question

Hello,

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?

Thank you!

Answer 1

I'm not a big fan of the tradional way of using includes(). By inserting includes based on some condition, you're basically using them as function calls. That can lead to all sorts of messes as the code in those included files resides in the global scope, potentially conflicting with other code or causing ambiguities about whether certain things are defined.

What I usually do is include all the PHP files that might be needed at the top of index.php. Then, instantiate objects or call functions based on the actions requested. And to answer your immediate first question, no, that does not slow down the app in any noticable way. Esp if you are using a caching system.

(this is just simplified pseudocode)

include( 'someclass.php');  //contains Some Class definition
include( 'someclass2.php');  //contains Some Class definition
include( 'someclass2.php');  //contains Some Class definition

switch( $action)
{
    ACTION_REGISTRATION:
       $sc = new SomeClass();
       $html = $sc->DoSomething();
       break;

    ACTION_SOMETHINGELSE:
       $sc = new SomeClass2();
       $html = $sc->DoSomeOtherThing();
       break;

    ....

}

//insert into template

echo $html;

Answer 2

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/

Answer 3

Actually, what you have here is the beginnings of a simple MVC structure -- index.php is acting as your router and the code in your /actions folder are acting as combined controllers and models. Your /views/* are, of course, acting as views. You'd be better transitioning this model over to MVC or HMVC (Hierarchical Model View Controller) as it would make "modularizing" the system easier.

That being said, some things to be aware of:

• You cannot trust user input -- or things which could be user input.

  index.php?action= // This counts as user input
  

• For your views it would be better to have a render function that you call when you want to render your views -- or rather, one that when calls echo's the view to the client -- that way, if you need to send custom headers you don't need to recode six views just to prevent data from being sent before your headers.