Interesting the mix of replies on this topic.
I use my own MVC Framework. I will never go back to doing things the way I did before. When you start to get very huge applications, it’s can be a nightmare to maintain and evolve to work with new features and requirements. So, separation of things into the various MVC layers makes a cleaner more manageable design.
For those that throw function libraries into a main include, what if you jsut don’t need all those libraries on every page? With MVC, you dynamically load only what you need for a particular functionality. I’d gladly trade off a few microseconds for less scratching my head when it comes to how am I gonna work in some new functionality.
Most of my reusable includes are outside of the web root. I use XAMPP in the opt folder on Linux.
/opt/myframework/config (server specific config)
/opt/myframework/includes
In the includes:
auth/
db/
debug/
error/
export/
html/
ldap/
log/
mvc/
mail/
states/
types/
xml/
In the webroot, I have:
opt/xampp/htdocs/app1
opt/xampp/htdocs/app2
opt/xampp/htdocs/app3
Inside an app folder:
config/ (app specific config)
css/
java/
images/
realm/
template-cache/
The realm folder contains related sets of sub applications. Inside a realm folder would be at least:
models/
templates/
and optionally
includes/
web-services/
Each template folder has an optional nav.tpl file. It contains a category name and set of links to the sub applications. If the file exist, the framework will pick it up and stick it into the left side main application navigation automatically. So, I can drop in new sub applications easily without having to change any of the main templates.
I use mod_rewrite to alter the URL:
http://msite.com/app1/realm/model/event
becomes
http://msite.com/app1/index.php?realm=some-realm&model=some-model&event=some -event
Every application has a default realm which contains the an error model, a login model, logout model, maintenance model. The default templates contain templates for each for the above models, plus common data output utilities, like result.tpl which prints a beautiful table for any 2d array of output from a database query, complete with optional pagination.
index.php loads my controller. The controller looks for the model named some- model and loads it. If the model is not found, it loads the error model and sends it the error code for “Model not found”. If the model exists, the controller checks if login is required and if not logged in, loads the login model instead, remembering the path of where the user was trying to go so it can take them there once they’ve logged in. Also, the controller looks at the event the user is requesting and checks if it’s a restricted event. If so, it looks up that user’s membership in any group that is allowed access to that event. If not a member, the error models is loaded with a “Your not Authorized” message.
Each model is derived from a parent model which gives the same base functionality, like session management, database connectivity, creating the base view which loads the main templates for that sites look and feel. Adding a new page can be as simple as creating a new empty model derived from one of the parent models and calling the display() function. Only a few lines of code. If I need to output a phone list of all employees. I add just a few lines: query = “some sql”, execute query, fetch all to array, assign result template, assign result array, display.
As I said, I’ll never go back to the old way of doing things. I’m still learning, but MVC, OOP has made things much easier without a doubt. It’s a “night and day” difference.