6. Le modèle MVC

Illustration 1: Le modèle vue-contrôleur. Source : http://tahe.developpez.com/web/php/mvc/?page=introduction

Implémenter le modèle MVC dans un projet

L'approche MVC change les habitudes de programmation : fini les appels directs à des pages ! Il faut impérativement passer par le contrôleur, qui va vérifier les droits et réorienter vers le module adapté.

Pour faire simple, on distingue les trois composants :

• la vue, l'interface utilisateur, est générée en Smarty qui, rappelons le, permet de séparer de façon importante le code de l'application de l'affichage ;
• le modèle, ou couche métier, est géré par deux types d'objets (au sens non UML) : les classes, basées par exemple sur ObjetBDD pour tout ce qui concerne l'accès aux bases de données, et les pages de traitement, qui contiennent la logique métier.
• le contrôleur va s'occuper de l'enchaînement des pages, vérifier les droits, gérer le login.

Les deux premiers composants sont déjà connus : la vue, ce sont les templates Smarty. Le modèle, se sont les classes et les modules contenant le code de l'application. Par contre, le contrôleur est un nouveau composant, dont le rôle se limite à gérer le fonctionnement général de l'application ; il est générique, et peut être réutilisé pour d'autres applications. Comment l'implémenter ?

Le contrôleur

Le contrôleur est constitué d'une page qui va être appelée systématiquement, soit par le biais d'un include, soit être le point d'entrée unique de l'application (page main.php ou index.php, unique lien référencé dans toutes les pages). Cette solution est en général préférable : elle limite l'accès à l'application à un seul point d'entrée.

Cette page va réaliser les opérations suivantes :

• mise en place des paramètres
• identification de l'utilisateur
• vérification, en fonction de l'action demandée, que l'utilisateur dispose des droits nécessaires
• vérification le cas échéant des données entrées (analyse des variables transmises, pour vérifier leur cohérence)
• exécution des modules de traitement
• enfin, génération des pages HTML en retour (appel des pages php qui vont générer les modèles Smarty).

Voici un schéma simplifié de fonctionnement d'un contrôleur :

Les avantages d'utiliser un contrôleur

Le contrôleur va s'occuper de toutes les opérations récurrentes : gestion de l'identification, gestion des droits, génération du menu à la volée, etc. Ainsi, il ne sera pas nécessaire d'inclure du code spécifique dans chaque page de l'application, pour s'assurer que les droits sont bien gérés, etc. Cela évite les oublis et simplifie le code.

Si vous prenez la précaution de mettre votre code dans des sous-dossiers, aucune page ne pourra être appelée indépendamment (sans passer par le contrôleur) sans déclencher d'erreur. Prenons un exemple :

- le contrôleur est situé à la racine ;

- la page à exécuter est gestion/moncode.php, et doit charger le fichier de classe classes/mesclasses.inc.php. Nous avons le code suivant dans gestion/moncode.php :

1. include_once 'classes/mesclasses.inc.php' ;

Le contrôleur va, au moment de traiter le module, réaliser un include :

1. include 'gestion/moncode.php' ;

Comme il est positionné à la racine de l'application, la commande include_once, située dans moncode.php, sera correctement exécutée : le chemin d'accès à mesclasses.inc.php est bien décrit par rapport à la racine (on exécute le code du module avec un include, c'est toujours le contrôleur qui garde « la main »).

Par contre, si nous essayons de charger directement la page gestion/moncode.php, le dossier de démarrage du script est gestion. La commande include_once n'aboutira pas, le chemin d'accès à mesclasses.inc.php aurait dû être ../classes/.

Décrire la cinématique dans un fichier ou en base de données

À partir du moment où vous décidez d'utiliser un contrôleur, vous pouvez également envisager de décrire toute la cinématique de votre application soit dans un fichier (xml, par exemple), soit en base de données. Cela vous permet de définir, pour chaque module :

- les droits nécessaires ;

- les modules antérieurs devant être appelés avant l'exécution du module courant, pour éviter, par exemple, une seconde écriture en base de données ;

- les modules qui seront appelés ensuite, en fonction des codes de retour.

Vous pouvez également en profiter pour générer automatiquement votre menu, en indiquant, pour chaque module devant être appelé depuis le menu, sa position, les libellés à afficher, etc.

Les URL conviviales

L'appel à un module va être réalisé systématiquement en utilisant le code (par exemple) :

http://localhost/proto/index.php?module=listePersonne

Pour simplifier l'écriture du lien, et le rendre plus facile à manipuler, nous allons le modifier ainsi :

http://localhost/proto/module-listePersonne

Bien évidemment, cette page n'existe pas... Nous allons utiliser une fonction d'Apache, qui permet de redéfinir les adresses demandées.

Pour cela, créons le fichier .htaccess à la racine de notre application, qui contiendra les lignes suivantes :

1. RewriteEngine on
2. RewriteRule ^module-(.*)&*(.*)$ /proto/index.php?module=$1&$2

Il faut auparavant avoir activé le mode Rewrite dans Apache (sous Ubuntu ou Debian) :

1. a2enmod rewrite
2. service apache2 restart

Cette méthode permet également de fournir des variables complémentaires. Nous pourrions ainsi taper le lien suivant :

http://localhost/proto/module-lirePersonne&id=5&type=I

qui serait équivalent à :

http://localhost/proto/index.php?module=lirePersonne&id=5&type=I

Ces URL sont plus faciles à manipuler et permettent de masquer en partie le fonctionnement global de l'application. D'autres redirections sont possibles, les possibilités de configuration sont étendues.

Les avantages et les inconvénients de la méthode

Utiliser un framework apporte beaucoup d'avantages : tous les mécanismes utilisés par le framework ne sont plus à coder. On le voit ici, où le menu est généré automatiquement, les droits bien implémentés partout... On est également obligé de s'astreindre à une certaine rigueur, ce qui n'est pas forcément une mauvaise chose.

Une fois que le framework est maîtrisé, il est très rapide d'y intégrer un nouveau module, il suffit en général de faire un déclaration dans un fichier quelconque pour qu'il soit pris en charge. Si le framework est un projet actif, on peut également récupérer toutes les évolutions assez facilement, soit pour intégrer de nouvelles fonctionnalités, soit qui corrigent les bugs des versions précédentes.

Par contre, il faut prévoir un certain temps d'apprentissage pour le maîtriser, et on est « bloqué » si celui-ci ne répond pas aux besoins. De même, si on doit utiliser des mécanismes particuliers, par exemple pour gérer les droits selon une logique particulière, cela peut devenir très compliqué.

Attention toutefois : un framework, qui intègre par défaut un certain nombre de mécanismes, peut vite devenir un « gouffre » en terme de ressources. Entre décrire un menu « à la main » dans une page HTML, et utiliser un script de génération automatique, le temps de traitement côté serveur ne va pas être le même ! Pour de petites applications, cela peut très bien ne pas poser de problème, mais si les pages concernées sont consultées par plusieurs milliers d'utilisateurs en même temps, le gain de développement peut facilement être perdu par la puissance supplémentaire nécessaire...

En conclusion : les frameworks sont très utiles pour standardiser et sécuriser une application, mais doivent être correctement choisis en fonction de ce que l'on veut faire, et doivent toujours être étudiés sur le plan de la performance.

Attention au choix des outils !

En matière informatique, les effets de mode sont permanents... Tel langage, encensé à telle période, devient « has been » quelques années plus tard. Pour les outils, c'est pareil, et les frameworks ne dérogent pas à la règle.

De plus, certains outils ont une image « professionnelle » : cela veut souvent dire qu'ils sont complexes, et nécessitent un investissement fort avant de pouvoir les utiliser. S'ils bénéficient de mises à jour régulière, c'est souvent pour rajouter des fonctionnalités et donc, complexifier encore un peu plus l'outil.

Aujourd'hui, ce qui est « à la mode », c'est le développement objet. Mais chaque langage a ses propres spécificités : si vous développez en Java, vous devrez impérativement coder uniquement en objet. Si vous travaillez avec PHP ou Python, vous pouvez combiner des objets au sein de code procédural : cela donne une souplesse sans commune mesure.

Certains frameworks PHP ne jurent que par le « tout objet » : c'est un non-sens. On complexifie inutilement le développement, ce qui entraîne en général des problèmes de performance (Java est, lui, pseudo-compilé, alors que PHP et Python ne sont qu'interprétés). Cest notamment le cas de Symphony, qui est actuellement LE framework à la mode, mais qui ne fonctionne qu'en mode tout-objet, et qui nécessite, de plus, l'apprentissage d'un langage complémentaire pour décrire l'application...

Avant de décider de votre plate-forme de développement, posez-vous quelques questions :

- le langage m'est-il imposé (l'ajout de modules dans Qgis, par exemple, vous imposera de travailler avec Python) ?

- ai-je besoin de performances ? Si oui, orientez-vous plutôt vers Java, qui s'exécutera toujours plus vite que PHP et supportera probablement mieux la charge au prix, il est vrai, d'un développement plus complexe ;

- quel framework utiliser ? Quel est celui qui, tout en semblant pérenne, me facilitera le travail au prix d'un apprentissage réduit ?

- si je travaille dans une société, en existe-t-il certains qui sont déjà utilisés ? Peut-on en choisir un autre ? À contrario, si je cherche un emploi, le framework que je préférerais utiliser fait-il l'objet de recrutements ?