Longtemps j'ai fait du MVC sans le savoir. Voici comment je procède quand je dois développer une petite appli vite fait j'ai toujours l'habitude d'utiliser le modèle suivant, qui est un "mini-mvc" :
Tout passe par index.php, c'est en général le seul script accessible. Les autres sont dans des dossiers (comme "includes/") avec un .htaccess pour en interdire l'accès.
Une autre méthode consiste à définir une constante dans index.php, et dans tous les autres scripts on vérifie que cette constante est définie : si ce n'est pas le cas => erreur. Mais c'est un peu plus pénible que le .htaccess
En gros, index.php ressemble à ça :
Code :
- index.php
- pages/
- *.php
- templates/
- *.php
Tout passe par index.php, c'est en général le seul script accessible. Les autres sont dans des dossiers (comme "includes/") avec un .htaccess pour en interdire l'accès.
Une autre méthode consiste à définir une constante dans index.php, et dans tous les autres scripts on vérifie que cette constante est définie : si ce n'est pas le cas => erreur. Mais c'est un peu plus pénible que le .htaccess
En gros, index.php ressemble à ça :
Code PHP :
<?php
include 'includes/common.php'; // mes includes
// lecture de la page demandée
$page = isset($_GET['page']) ? $_GET['page'] : 'default';
$page = basename($page); // protection sommaire pour éviter une faille avec ?page=../../.....
if (!is_file('pages/'.$page.'.php')) {
$page = 'default';
}
// partie métier, pas d'affichage
include 'pages/'.$page.'.php';
// affichage via un script simpliste
include 'templates/'.$page.'.php';
?>
Ainsi je me contente d'appeler le bon script dans "pages/" qui se contente de faire des calculs & cie.
Et ensuite j'inclus le script correspondant dans "templates/". Pas de moteur de template, juste de l'auto-discipline : le script "template" ne doit contenir que des instructions d'affichage, aucun traitement. Et inversement pour le script "page".
C'est tout simple, et ça n'a pas grand-chose à voir avec la POO dans ce cas. La POO dans un schéma comme celui là ne fait qu'apporter des contraintes supplémentaires, un "cadre" plus strict et donc évite de pourrir le schéma (parce que si on ne s'auto-discipline pas dans cette structure, on peut très bien la faire exploser, ce qui n'est pas le cas quand on utiliser un framework comme Zend où si on ne suit pas la route tracée, ça ne marche tout simplement pas).
Pour avoir un "vrai" MVC pour les puristes, il faudrait créer une classe View, Model, et Controlleur pour encapsuler tout ça. Mais de base, on pourrait renommer "index.php" en "controller.php", "pages/" en "models/" et "templates/" en "views/" et ce serait presque du du MVC comme dans les manuels .
Quant au débat sur l'utilité de la POO, je vous assure que quand on s'y met c'est absolument indiscutable. Rien à voir tant en terme de lisibilité globale du code qu'en terme de maintenance et d'évolution de l'application. Mais le but de mon message c'est surtout de montrer qu'on n'est pas obligé de TOUT prendre dans un modèle. On peut très bien se contenter du concept global, et l'adapter à la taille du projet