Un framework se défini par "cadre d'application". Le MVC signie Modèle Vue Contrôleur. Il s'agit d'un design pattern consistant à séparer la vue (ce qu'on voit dans le navigateur), le modèle de données (le plus souvent l'accès à la base) et le contrôleur qui fait la jonction. Cette définition est en fait un peu simpliste, mais permet de bien voir le rôle de chacuns. D'une manière générale, l'utilisation de design pattern et notamment celui du MVC demande du temps pour étre assimilé. D'autant plus qu'on le retrouve souvent dans des frameworks beaucoup plus riches en général. Je ne m'intéresse ici à aucun framework en particulier, mais juste au pattern MVC. Le but final de tous ces articles sera d'avoir une vue d'ensemble bien construite de ce qu'un framework typique peut proposer.

PHP est longtemps resté un langage réputé "pour débutant" et donc peu prisé par les entreprises, notamment à cause de son coté "bordel". En effet, avec php, il n'y a pas séparation entre le coté serveur et le coté client, ce qui veut dire que le même fichier peu contenir

  • du php
  • du SQL
  • du javascript
  • du CSS
  • du (X)HTML

Non seulement ces langages peuvent se retrouver tous ensembles dans la même page, mais en plus, depuis l'avènement d'AJAX, on peut réaliser des appels de la page sur elle-même en ajax ou en http traditionnel. On perd vite les pédales entre tous les appels, tous les langages, ajax pas ajax, et pour peu qu'on ajoute un formulaire, des redirections conditionnelles (qu'on peut réaliser en php avec header(), en html ou en javascript avec window.location et c'est fini la page seule est devenue un godzilla incontrôlable qu'il va falloir abattre.

D'un point de vue plus théorique, l'utilisation du MVC permet de revoir toute la structure d'un programme (j'utilise le terme "programme" et non "site"). En effet, la méthode courante stipule qu'une bonne séparation des différents acteurs implique leur écriture dans des fichiers séparés. Ce qui se résume en gros par : la structure du programme est la structure des fichiers ET la structure des fichiers est la structure du programme. C'est en fait une horreur de conception. Penser comme ça signifie qu'on ne fait pas ce qu'on doit faire, mais ce qu'on peut faire, il signifie que le fonctionnel n'est réfléchis qu'après l'opérationnel. En gros, ça signifie que le programme est mal ou pas pensé (Attention, je ne dis pas le prog est mauvais, je dis juste qu'il est pensé à l'envers).

Pour illustrer un peu, je vais prendre un espace membre tel qu'il est fait dans 90% des cas. On retrouve donc un fichier connection.php, un fichier inscription.php, un fichier passperdu.php et un fichier "protégé" index.php. Chacun d'eux utilise les fichiers fonctions.php, classes.php, db.php Lorsqu'on arrive sur index.php, la page est protégée, et redirige vers connection.php pour que le gars se loggue, elle inclue donc fonctions.php qui va probablement définir des fonctions bourrées de variable globales ou de avoir des paramètres excessivement élevés, classes.php qui définira sûrement les méthodes pour gérer l'espace membre et enfin db.php

Que peut-on faire pour simplifier ? Simplement rassembler les acteurs par intérêt et non par chronologie.

class user {
   
    private isConnected = false;
    private user_id = null;

    function connection() {
    }

    function inscription() {
    }

    function passperdu() {
    }

    function isConnected() {
    }

    function isLoginAlreadyExists() {
    }

    function changePass() {
    }

    // ..........
}

Il est possible que l'interêt majeur du MVC vous échappe encore, et c'est normal sans exemple concret. Sachez cependant qu'avec ceci, il est déjà possible de voir les futures possibilités. Par exemple, en conservant le format class/méthode (qu'on nommera contrôleur/action), on pourra définir une norme pour la réécriture d'URL. Par exemple http://toto.com/user/connection appelera automatiquement le méthode connection de la classe user.

N'hésitez pas à fouillez dans la réécriture d'URL avec ou sans apache.

Aller à la 2ième partie