Discussion :

[bpesquet]

Bonjour,

tout d'abord un grand merci pour ce tuto, je débute en php et il m'a été d'une grande aide.
J'aurais une question sur la partie POO, plus précisément la classe Modele. J'aimerais savoir s'il est possible de mettre en place une requête préparée du type:

(...)

Merci pour vos réponses!!!

Bonjour et merci pour les compliments. Oui, il serait tout à fait possible d'ajouter à la classe Modele la possibilité d'exécuter des requêtes préparées, c'est même une bonne idée que je prévois d'intégrer à la prochaine version de l'article

On pourrait ajouter à la méthode executerLecture un paramètre indiquant si la requête comporte des paramètres, et utiliser dans ce cas une requête préparée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
abstract class Modele {
 
    private $bdd;
 
    protected function executerLecture($sql, $valeurs = null) {
        if ($valeurs == null) {
            $stmtResultats = $this->getBdd()->query($sql);
        }
        else {
            $stmtResultats = $this->getBdd()->prepare($sql);
            $stmtResultats->execute($valeurs);
        }
        return $stmtResultats;
    }
...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
class Commentaire extends Modele
{
    public function lireListe($idBillet)
    {
        return $this->executerLecture(
            'select * from T_COMMENTAIRE where BIL_ID=?', array($idBillet));
    }
...

Ceci n'est qu'une possibilité parmi d'autres, qui pourra j'espère vous aider un peu à avancer.

Cdlt,

[bpesquet]

L'article Evoluer vers une architecture MVC en PHP vient d'être mis à jour.

Au menu, un nouveau chapitre consacré à la construction d'un framework MVC minimaliste à partir des classes déjà écrites, ainsi que quelques améliorations de détails.

Je suis preneur de toute critique me permettant d'améliorer encore l'article.

Bonne lecture !

[bedomon]

Une petite remarque concernant la forme abrégé qui est cité dès le début, je pense que c'est une mauvaise pratique que de la mettre en avant :

• php 5.3 est toujours la version la plus utilisée (donc il faut short_open_tag a on )
  
  • ET http://pear.php.net/manual/en/standards.tags.php
• rend la lecture moins intuitif (un echo "saute" au yeux tandis que le signe = se noie dans la masse)

Je comprends qu'il faut suivre les évolutions du language, mais c'est quand même le monde professionnel qui dicte sa loi et (je pense) il vaut mieux donner les bonnes pratiques et les standars aux débutants

[papajoker]

Bonjour bedomon,

Pour moi, ce n'est plus pear la référence mais PHP Framework Interop Group (fig)
https://github.com/php-fig/fig-stand...ng-standard.md et short est ok

c'est quand même le monde professionnel qui dicte sa loi

oui, et il ont choisi fig : c'est ZF, Symfony2, Drupal, Jomla et pear!...
la liste http://www.php-fig.org/

[Tsilefy]

PHP 5.3 est en fin de cycle de vie. Si l'on vise des débutants, mieux vaut faire le saut à PHP 5.5 directement (ou au moins à 5.4). On peut toujours développer avec la syntaxe de 5.3 sur les versions ultérieures, mais les apports sont bien plus avantageux.

C'est différent bien sûr si on a déjà du code existant à maintenir (quoique là aussi les incompatibilités sont mineures et facilement corrigeables entre 5.3 et 5.4).

[Tsilefy]

Pear a toujours été un truc hybride où on trouvait le meilleur et le pire.

[bedomon]

Même s'il est en fin de vie de cycle, ce n'est pas ce qui va motiver les DSI des différentes boites ne vont pas faire ces changements, Les réalités et contraintes professionnels sont (hélas) comme elles sont...

[Tsilefy]

Je n'ai pas lu tout le code, mais voici quelques suggestions pour la prochaine version:

- éliminer les propriétés statiques (ex ici et ici). L'utilisation de propriétés statiques dans ce contexte pose des problèmes de clarté de code, d'incertitude, de dépendance trop étroite et de manque de flexibilité. Il est préférable d'injecter explicitement les dépendances, et si besoin d'utiliser un service container/dependency injection container.

- Ce problème se pose par exemple concrètement ici. Tu es obligé de tester entre le fichier de config prod et dev dans cette méthode. Du coup, la méthode a deux responsabilités (tester l'existence du fichier config et charger le fichier), alors qu'une méthode ne doit en avoir qu'une. De plus, la responsabilité de choisir le bon fichier ne devrait pas se trouver dans cette classe, mais laissée à l'utilisateur. En l'état, la classe ne permet pas de changer le type d'environnement sans modifier la classe elle-même, et puisque la valeur retournée est statique, on ne peux pas non plus utiliser deux environnements en même temps, alors que ce serait très pratique par exemple d'avoir deux contrôleurs, une dev et une prod.

- Introduire les test unitaires?

[Marty]

Excellent article qui explique très bien via un exemple simple et très progressivement le mécanisme MVC.
Je connaissais les principes, j'avais commencé à apprendre via la lecture d'un ouvrage sur ZF (il y a longtemps), mais cessé pour diverses raisons, notamment pas assez d'expérience en PHP.
Cet article permet de remettre le pied à l'étrier et j'en vois toute la pertinence et l'utilité pour mon site perso (pour commencer) que je veux totalement restructurer avec de la "bonne programmation" ! ;-)

Bien évidemment il va nécessité quelques relectures approfondies pour tout bien comprendre.
Je n'ai pas souvenir d'en avoir vu de comparable.

Un "vif merci" est un donc un doux euphémisme pour dire ce qu'il apporte

[Sirus64]

J'aime bien l'approche du "je vais vous montrer comment marche un framework MVC en en construisant un".

Ce qui me gène c'est l'opposition MVC vs modèle en couches : ils ne sont pas incompatibles et sont même utilisés conjointement. Tu trouves généralement trois couches : présentation, affaire, données. Pour moi le MVC s'insére dans la couche présentation.

Étant plus .Net (et PHP dans une autre vie), j'ai plus tendance à proposer MVC pour des sites classiques pour l'IHM avec un modèle en couches pour le backend :
- présentation va sur un cluster dans une DMZ avec un reverse proxy (et une coupure de session) pour y accéder
- affaire sur un autre cluster dans une autre zone réseau avec un firewall entre les deux,
- données encore dans une autre zone avec firewall pour le cluster affaire et non accessible de la DMZ

Le tout est scalable, si plus de charge, on augmente le nombre de machine et/ou la capacité du serveur BD.

Après de manière générale, je suis pour l'utilisation de framework : cela permet d'avoir une meilleure sécurité sur des éléments auquels on n'aurait pas pensé. Dans ces frameworks, j'utiliserais à coup sur un ORM afin d'éviter les injections SQL, même si les performances sont quelques peu dégradées.

[jb_gfx]

Très bon article.

Si je peux me permettre une toute petite remarque. Je pense que certaine parties du code qui utilisent beaucoup de conditions imbriqués gagneraient en clarté simplement en inversant les tests et évitant d'imbriquer les conditions.

Par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
// Traite une requête entrante
public function routerRequete() {
  try {
    if (isset($_GET['action'])) {
      if ($_GET['action'] == 'billet') {
        if (isset($_GET['id'])) {
          $idBillet = intval($_GET['id']);
          if ($idBillet != 0) {
            $this->ctrlBillet->billet($idBillet);
          }
          else
            throw new Exception("Identifiant de billet non valide");
        }
        else
          throw new Exception("Identifiant de billet non défini");
      }
      else
        throw new Exception("Action non valide");
    }
    else {  // aucune action définie : affichage de l'accueil
      $this->ctrlAccueil->accueil();
    }
  }
  catch (Exception $e) {
    $this->erreur($e->getMessage());
  }
}

Deviendrait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
 
// Traite une requête entrante
public function routerRequete() {
  try {
 
    // si aucune action définie : affichage de l'accueil
    if (!isset($_GET['action'])) {
      $this->ctrlAccueil->accueil();
      return;
    }
 
    if ($_GET['action'] !== 'billet') {
      throw new Exception("Action non valide");
    }
 
    if (!isset($_GET['id'])) {
      throw new Exception("Identifiant de billet non défini");
    }
 
    $idBillet = intval($_GET['id']);
 
    if ($idBillet === 0) {
      throw new Exception("Identifiant de billet non valide");
    }
 
    $this->ctrlBillet->billet($idBillet);
 
  }
  catch (Exception $e) {
    $this->erreur($e->getMessage());
  }
}

[Tsilefy]

@jb_gfx: tu n'as pas du lire la dernière version du code, ce problème a été traité.

[jb_gfx]

Je n'ai pas regardé le code sur GitHub, seulement l'article.

[bpesquet]

Je remercie toutes les personnes qui ont donné leur avis sur l'article. Voici mon point de vue sur certaines remarques.

Au passage, je signale que j'ai une expérience professionnelle du développement, mais pas du développement Web. J'ai aussi mis l'article en ligne pour avoir un retour de gens qui ont ce recul.

De plus, le cours php d'origine est donné à des étudiants de BTS SIO qui ont seulement quelques mois de programmation derrière eux. Je suis obligé de simplifier beaucoup de choses, et même en l'état c'est parfois limite pour eux

Une petite remarque concernant la forme abrégé qui est cité dès le début, je pense que c'est une mauvaise pratique que de la mettre en avant :

• php 5.3 est toujours la version la plus utilisée (donc il faut short_open_tag a on )
  
  • ET http://pear.php.net/manual/en/standards.tags.php
• rend la lecture moins intuitif (un echo "saute" au yeux tandis que le signe = se noie dans la masse)

J'ai eu exactement le point de vue inverse venant d'autres développeurs. Comme quoi il n'y a pas de consensus là-dessus. Personnellement, je trouve que la forme abrégée rend le code plus concis sans être illisible.

Je n'ai pas lu tout le code, mais voici quelques suggestions pour la prochaine version:

- éliminer les propriétés statiques (ex ici et ici). L'utilisation de propriétés statiques dans ce contexte pose des problèmes de clarté de code, d'incertitude, de dépendance trop étroite et de manque de flexibilité. Il est préférable d'injecter explicitement les dépendances, et si besoin d'utiliser un service container/dependency injection container.

- Ce problème se pose par exemple concrètement ici. Tu es obligé de tester entre le fichier de config prod et dev dans cette méthode. Du coup, la méthode a deux responsabilités (tester l'existence du fichier config et charger le fichier), alors qu'une méthode ne doit en avoir qu'une. De plus, la responsabilité de choisir le bon fichier ne devrait pas se trouver dans cette classe, mais laissée à l'utilisateur. En l'état, la classe ne permet pas de changer le type d'environnement sans modifier la classe elle-même, et puisque la valeur retournée est statique, on ne peux pas non plus utiliser deux environnements en même temps, alors que ce serait très pratique par exemple d'avoir deux contrôleurs, une dev et une prod.

Ces remarques sont pertinentes. Pour écrire cette classe, je me suis basée sur celle-ci en visant une simplicité maximale pour ne pas compliquer encore le framework. Du coup, cette classe n'est pas aussi découplée qu'elle pourrait l'être.

- Introduire les test unitaires?

J'y réfléchis pour la prochaine version...

Ce qui me gène c'est l'opposition MVC vs modèle en couches : ils ne sont pas incompatibles et sont même utilisés conjointement. Tu trouves généralement trois couches : présentation, affaire, données. Pour moi le MVC s'insére dans la couche présentation.

Étant plus .Net (et PHP dans une autre vie), j'ai plus tendance à proposer MVC pour des sites classiques pour l'IHM avec un modèle en couches pour le backend :
- présentation va sur un cluster dans une DMZ avec un reverse proxy (et une coupure de session) pour y accéder
- affaire sur un autre cluster dans une autre zone réseau avec un firewall entre les deux,
- données encore dans une autre zone avec firewall pour le cluster affaire et non accessible de la DMZ

Le tout est scalable, si plus de charge, on augmente le nombre de machine et/ou la capacité du serveur BD.

Je n'ai peut-être pas été assez clair sur ce point. Ce que je cherche à faire comprendre, c'est que le modèle MVC n'est pas un modèle en couches. On entend trop souvent parler de "couche Modèle" ou de "couche Vue".

Je suis d'accord avec toi, on peut très bien avoir une architecture n-tiers avec pas exemple la couche de présentation (serveur Web) en MVC.

Après de manière générale, je suis pour l'utilisation de framework : cela permet d'avoir une meilleure sécurité sur des éléments auquels on n'aurait pas pensé. Dans ces frameworks, j'utiliserais à coup sur un ORM afin d'éviter les injections SQL, même si les performances sont quelques peu dégradées.

J'ai renoncé à introduire un ORM comme Doctrine pour rester simple, et aussi parce que (je parle d'expérience) ce n'est pas toujours la solution miracle. Ca pourrait être une piste d'extension du framework.

Très bon article.

Si je peux me permettre une toute petite remarque. Je pense que certaine parties du code qui utilisent beaucoup de conditions imbriqués gagneraient en clarté simplement en inversant les tests et évitant d'imbriquer les conditions.

Il est vrai que le code des routeurs intermédiaires est lourdingue. Ce souci est résolu dans la version finale, celle du framework où le routage est automatisé.

De plus, ta solution est, je pense, un peu plus difficile à lire pour des étudiants peu expérimentés qui s'emmêlent vite les crayons avec les structures de contrôles.

[distrikt26]

J'ai suivi cet article avec beaucoup d'attention et j'ai réussi à créer mon 1er contrôleur/modèle/vue. (je débute totalement en poo et MVC)
par contre je ne sais pas à quel moment formater les données.
J'y arrive en ajoutant une fonction dans le framework --> vue.php mais ce n'est pas très pratique car ce fichier va vite être bourré de fonctions et de plus il est appelé à chaque fois. Ce que je veux faire c'est juste un number_format sur un chiffre issu de ma BDD. Donc j'imagine que l'on doit ajouter une fonction dans le contrôleur ou le modèle concerné (produit dans mon cas) mais comment faire ?

Merci de votre attention

[Tsilefy]

Tu formates les données au tout dernier moment, avant de les afficher. Le modèle ou le contrôleur n'ont pas à savoir comment formater un chiffre, ils doivent être indépendants des contraintes d'affichage. Cette solution te donne le maximum de flexibilité et ne crée pas de dépendances inutiles pour ton projet (la chose à éviter absolument).

[foxbille]

Bonjour,
Eh bien c'est tout simplement le meilleur article que j'aie jamais lu sur le sujet ! Il m'a été extrêmement profitable car il fait parfaitement le lien entre ce que je sais faire et ce que je ne parvenais à comprendre que de manière imparfaite. La méthode "par approche" que je n'ai rencontrée qu'une seule fois dans ma vie de développeur (lors de formations à Clipper... on ne rit pas) me convient parfaitement et me parait trés efficace au plan de la pédagogie. Bravo et merci beaucoup ! Je recommande !!!
Eric

[Paulter]

Merci pour cet article. Mais j'ai juste une petite question.

Je travail sur une aplication en intranet et je n'ai au départ pas pensé à bien organiser mon code. Résultat je me retrouver avec un dizaine de fichier php à la racine du répertoire web. Il n'y a pas énormement de boulot pour réorganiser le tout vers une architecture MVC car dans l'ensemble les fichiers n'ont qu'on seul objectif (Afficher un formulaire, supprimer une occurence dans la bdd,...) si ce n'est mon fichier index.php.

Bref, tout ça pour dire que c'est un petit projet. Et du coup est-ce que ça vaut le coup d'utiliser un framework php pour ça ? J'ai du mal à cerner quand utiliser un framework php déjà existant et relativement costaud et quand rester sur une architecture MVC "fait maison" ?

[rawsrc]

Salut,

Une architecture MVC reste une architecture MVC qu'elle soit maison ou pas.
Une fois que tu maîtrise cette logique, rien ne t'empêche de pondre tes propres outils pour la mettre en place. De toute façon, n'importe quel codeur qui connaît le MVC devrait s'y retrouver assez rapidement.
Quant à savoir vers quoi s'orienter, la différence se joue plus en terme de fonctionnalités, de qualité de code et de support. Tout dépend de l'orientation future du projet à coder.

Plus c'est pérenne et amener à évoluer, plus il est conseillé de prendre de l'existant comme base de départ (micro-framework voire framework lourd), soit tu t'estime assez compétent pour baser la solution sur tes propres briques logicielles.
A vrai dire, je ne privilégie plus une voie par rapport à l'autre. J'ai vu des projets bâtis sur des frameworks existant complètement pourris et inversement, des solutions sur des briques logicielles perso très propres (bon il faut que le framework perso soit très bien documenté). Après les ayatollahs qui ne jurent que par une seule approche ont tendance à me gonfler sévère. Vu la complexité des projets, plusieurs voies sont possibles et parfois même le mix éclairé de plusieurs d'entre elles est très à propos pour peu que les dev soient compétents.

Pour les petits projets, les micro frameworks te soulagent des aspects fastidieux et redondants de tout site web, donc à moins d'avoir quelques classes tout prêtes de base, oriente vers un micro-framework.

[ABCIWEB]

Salut,

Je partage tout à fait l'avis de rawsrc.

Et dans ton cas si l'application est quasiment finalisée et qu'elle tourne correctement, t'as pas vraiment de raisons de changer, sauf pour apprendre et si tu as du temps devant toi. Tu pourrais adopter cette architecture pour tes nouveaux projets si cela te convient. Après que tu aies une dizaine de fichiers à la racine du site, ben c'est pas la fin du monde, c'est pas vraiment ce qui fait la différence niveau sécurité.