Mon MVC de base : m'aider à placer les éléments
Voici mon MVC de base que je tente faire. Je souhaiterais qu'on m'aide à placer les éléments.
Mon contrôleur se trouverait être l'index principal, le model sont mes deux requêtes et l'affichage
se trouve être le fichier show utilisé dans un template layout pour le codage html principal.
J'ai un peu de difficulté à couper mon fichier show vu qu'il y a deux affichages du model.
Voir si je peux mieux faire sans aller dans la complexité.
Mon index qui se trouve être le contrôleur pour le model.
<?php
// fichier /INDEX.PHP:
require_once('model/model.php');
$oArtiste = new Artiste($cxn);
require('view/show.php')
?>
Mon fichier de connexion en PDO.
<?php
// fichier /MODEL/CONNECT.PHP:
$dnsh = "mysql:host=localhost;dbname=ptg";
$user = "root";
$pass = "";
$cxn = new PDO($dnsh, $user, $pass);
$cxn ->setAttribute(PDO::ATTR_PERSISTENT,true); //a le même effet qu'un singleton, sans les inconvénients
$cxn ->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
Mon fichier model qui fait deux requêtes d'une liste et le détail.
<?php
// fichier /MODEL/MODEL.PHP:
include_once ('connect.php');
class Artiste
{
private $_conn;
public function __construct($cxn)
{
$this->_conn = $cxn;
}
public function lister()
{
$stmt = $this->_conn->prepare('SELECT * FROM artistes');
$stmt->execute();
return $stmt->fetchAll(PDO::FETCH_OBJ);
}
public function afficher($id = null)
{
$stmt = $this->_conn->prepare('SELECT * FROM artistes WHERE id = :id');
$stmt->bindParam(':id', $id, PDO::PARAM_INT);
$stmt->execute();
return $stmt->fetchAll(PDO::FETCH_OBJ);
}
}
La vue, je ne vois pas comment je peux séparer ma vue étant donnée que j'ai un bloc CSS et que j'ai deux affichages, un d'une liste et l'autre le détail.
<?php
ob_start() // fichier /VIEW/SHOW.PHP:
?>
<div class="wrapper">
<header class="header"></header>
<!-- .header-->
<div class="middle">
<div class="minheight">
<div class="container">
<main class="content">
<?php
$artiste_id = (empty($_GET['artiste'])) ? '1' : (int)$_GET['artiste'];
$AfficherArtistes = $oArtiste->afficher($artiste_id);
foreach($AfficherArtistes as $a_artiste)
{
echo $a_artiste->id . " " . $a_artiste->prenom . " " . $a_artiste->nom;
}
?>
</main>
<!-- .content -->
</div>
<!-- .container-->
<aside class="left-sidebar">
<main class="content">
</main>
<?php
$ListerArtistes = $oArtiste->lister();
foreach($ListerArtistes as $l_artiste)
{
echo "<a href='http://localhost/index.php?artiste=" . $l_artiste->id . "'>" . $l_artiste->prenom . " " . $l_artiste->nom . "</a></br>";
}
?>
<!-- .content -->
</aside>
<!-- .left-sidebar -->
</div>
<!-- .minheight-->
</div>
<!-- .middle-->
<footer class="footer">
</footer>
<!-- .footer -->
</div>
<!-- .wrapper -->
<?php $content= ob_get_clean(); ?>
<?php include_once('layout.php'); ?>
Et le template qui affiche la vue.
fichier /VIEW/LAYOUT.PHP:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<!--[if lt IE 9]>
<script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>
<![endif]-->
<title></title>
<meta name="keywords" content="" />
<meta name="description" content="" />
<link href="/view/style.css" rel="stylesheet">
</head>
<body>
<?php echo $content; ?>
</body>
</html>
Réponses apportées à cette discussion
Salut,
ton exemple est effectivement très basique.
Cependant, qui dit MVC dit Programmation Orientée Objet, ce qui sous-entend des classes spécialisées pour différents éléments. Le traitement des vues est donc en principe également géré par une instance d'une classe de gestion des vues. C'est en principe dans cet objet que tu vas construire les différents éléments de ta page et éventuellement les stocker jusqu'à ce que soit fait appel à une méthode du type afficher (ou souvent render() en anglais) qui va retourner l'ensemble de ce qui a été construit.
Schématiquement dans un MVC, ton contrôleur détermine quels paramètres ont été reçu pour savoir quelle page on doit construire. Partant de là, le contrôleur va sélectionner le ou les modèle(s) pour collecter les données appropriées, puis sélectionner les vues appropriées et envoyer ça à la classe de vues pour construire dynamiquement le code HTML qui sera retourné.
Ta classe MODEL ne devrait à cet égard jamais comporter une méthode afficher(), ce n'est absolument pas son rôle : dans un MVC, le modèle ne connait pas la vue et la vue ne connait pas le modèle : le contrôleur fait appel à l'un puis à l'autre pour leur faire faire ce qui leur est strictement réservé.
Dans ta structure, tu devrais avoir un unique contrôleur frontal, puis ce que j'appellerais un sous-contrôleur pour chaque page (voire pour certaines parties de pages), sous-contrôleur qui est seul à savoir de quelles données il a besoin et quoi faire avec, et quelles vues sont nécessaires. Puis ce sous contrôleur collecte les données, éventuellement effectue des traitements pour mettre ces données dans un format particulier et les envoyer à la vue avant de retourner le tout au contrôleur frontal qui va renvoyer la page construite vers le client.
En procédural, ça se fait un MVC:
http://developpeur-info.blogspot.ca/2013/06/php-mvc.html
Je souhaitais à partir des éléments que j'ai soumis.
De voir comment c'est fait et me servir de ce que j'ai de fait.
merci.
Oui, mais en procédural, c'est une simulation.
Le MVC est un Design Pattern composite. Mais qui dit Design Pattern dit également POO. Mais l'idée générale reste la même : on sépare les couches : le contrôleur, la couche de traitement, la couche de vue. Le traitement, c'est le modèle, et dans cette partie, on ne traite pas du tout l'affichage : comprendre cet aspect reste très important.
Mais ça ne veut pas dire que ce que tu as fait est irrattrapable, ça veut simplement dire que la partie affichage de ton modèle doit être migré dans une couche de vue qui sera appelée par le contrôleur. En d'autre termes, ton contrôleur va bien appeler ton modèle, mais pour en récupérer des données, puis il appellera ensuite la vue en lui communicant ces données et il récupèrera le code HTML construit sur cette base avant de le retourner vers la sortie.
PHP est tellement rendu plate et gazant que s'en est rendu suicidaire de continuer. Merci pour les explications Cyrano mais je cesse d'utiliser PHP. A date, je n'ai jamais vu un exemple simple qui englobe l'Orienté Objet, PDO et MVC dans aucun exemple de tutoriel.
Salut dancom5,
le problème soulevé est complexe.
Il faudrait se tourner vers les frameworks pour résoudre ça, et je reconnais que ça ne facilite pas la tâche tellement ces frameworks sont parfois compliqués à utiliser.
Donc pour ma part je ne dirais pas que c'est suicidaire, mais on est loin de la programmation procédurale des premières années de PHP, jusqu'à PHP3 inclus. On avait alors des besoins assez simples et on construisait des pages en « code spagghetti » avec du PHP, du HTML, les requêtes SQL, du CSS, une touche de JavaScript pour faire bonne mesure, le tout dans le même fichier. Mais les années ont passé, PHP s'est considérablement enrichi et l'orienté objet est entré dans le paysage en se perfectionnant de plus en plus au point qu'aujourd'hui, la POO de PHP n'a pas grand chose à envier à la POO de Java ou de C++ par exemple : en d'autres termes, PHP s'est professionnalisé. Mais ça implique d'aller beaucoup plus loin dans les concepts de programmation et d'intégrer par exemple les notions de Design Patterns qui viennent de Java à l'origine. Ces derniers sont conçus pour optimiser la programmation. Le MVC va plus loin encore en combinant plusieurs Design Patterns, mais l'idée générale reste la même : optimiser la programmation avec pour but principal de simplifier la maintenance et les évolution des programmes qu'on écrit.
Alors ça dépend toujours de ce que tu veux construire. Si c'est un simple site web relativement basique, la POO n'est pas obligatoirement la meilleure solution même si on peut utiliser quelques classes, ou on peut encore se tourner vers les CMS qui finalement ne demandent plus vraiment de programmation. Mais si tu veux construire quelque chose de plus complexe, comme une boutique en ligne par exemple, je dirais d'abord qu'il ne faut plus penser « site web » mais « application logicielle en ligne », et ça peut faire toute la différence dans l'approche : on isole les éléments et on les traite indépendamment les uns des autres, et modifier un élément ne doit pas affecter le fonctionnement des autres, c'est ça la réalité de la programmation optimisée. Un exemple simple intégrant POO + PDO + MVC, ça ne peut pas vraiment être simple.
Lâcher le PHP, c'est dommage, mais pour le remplacer par quoi ? Si c'est un langage orienté objet, tu te heurteras aux mêmes difficultés, alors que là, tu pars d'une base connue à laquelle il faut juste ajouter des connaissances. Ça dépend de tes objectifs à terme. Si c'est juste un hobby, je peux volontiers comprendre que ça devienne un peu déprimant de ne pas pouvoir avancer parce que tu ne trouves pas les solutions aux difficultés rencontrées, mais si tu gagnes ta vie avec ça, alors effectivement, tu as un gros problème qui ne peut être résolu qu'avec des formations appropriées pour compléter efficacement tes connaissances. Si tu veux une suggestion, je te recommande vivement d'essayer de trouver un bouquin qui s'intitule « Design Patterns - Tête la première », l'original est en anglais publié chez O'Reilly, je crois que la version française a été ré-éditée chez Dunod, sinon, tu peux peut-être le trouver d'occasion : ça vaut vraiment la peine parce tout y est très clair même si les exemples de code sont en Java, la syntaxe n'est pas difficile et assez proche de PHP pour que tu puisses transposer facilement. Là tu comprendras ce qu'est le MVC même s'il faudra commencer par intégrer les patterns simples au départ.
Bon courage
Bonjour Cyrano, je ne gagne pas ma vie avec la programmation. C'est seulement aider un ami à moi à faire un site de galeries d'images.
L'idée du site que je cherche à faire est la suivante:
Je fais les catégories à l'avance et les utilisateurs les utilisent.
Ils mettent leurs images à la catégories correspondantes qu'ils désirent.
Et les visiteurs affichent les images en fonction des catégories.
Une option pourrait consister à afficher par utilisateur les catégories/images.
J'ai tenter de faire une liste d'utilisateur à gauche et quand je clique
sur un utilisateur, on voit ses images ou bien ses catégories.
J'en était rendu à lister les utilisateurs et à afficher à droite le contenu.
J'avais fait en CSS une sorte de template pour afficher l'en-tête, le pieds, et les 2 colonnes qui se suivait dynamiquement toujours égaux.
Le code source dans mon premier message de ce topic le montre bien.
Avec tout ceci, j'ai tenter de le faire en MVC pour séparer la couche HTML du PHP par fichier comme dans le code source. Comme j'ai deux affichage avec du PHP "foreach", je n'arrivais pas à séparer en couche.
Dans toute l'aventure, j'ai tenter d'essayer plusieurs frameworks que je trouvais très compliqués à appliquer à mon cas sans suivre nécessairement le moule du framework.
Je pourrais le faire en procédural mais je chercher à utiliser l'orienté objet puisque je voulais éviter le codage "Spagatte".
Tous les exemples que j'ai pu trouver jusqu'à maintenant sont en procédural qui utilisent PDO ou bien en Orienté Objet mais qui n'utilise pas PDO.
Curieux de voir en 2014 qu'on n'est pas capable de voir des exemples qui n'utilisent pas PDO/POO/MVC ou simplement PDO/POO.
Un autre point qui me découage, tous les scripts dans les annuaires sont vieux genre 2001 et pas adaptés; à croire que le net est une poubelle pour être poli.
Je ne parle que d'affichage pas encore d'entrée de donnée comme un espace utilisateur et administrateur. Mais, pour toute de suite, je m'attarde que sur l'affichage d'une galerie d'image.
Avant, j'utilisais pour me faire des sites, les commandes et fonctions PHP qu'on retrouve dans l'index du site officiel de PHP, c'est comme cela que j'ai appris à utliser PHP.
C'était le fun puisqu'on pouvait faire des trucs que je trouvais intéressant. Les regexp, les functions, etc.
Dans mon message que voici, je crois que je cherche plus à m'exprimer même en sachant qu'un jour, je vais peut-être vouloir effacer certains messages.
J'amais, je vais sur des sites pour laisser mes penser aux hasards, à cause que le net c'est une foutu poubelle à la longue. Ça rends les messages obsolètent avec le temps et parfois gênant.
Dan.
Console-toi, tu n'es pas le premier à découvrir tout ça.
J'ai commencé le PHP en 2003 par frustration. À l'époque, j'étais bien incapable de programmer quoi que ce soit dans quelque langage que ce soit, ce n'était ni mon métier ni ma formation et je ne faisais que du HTML en hobby. Je voulais ajouter un livre d'or ou un petit forum sur un site statique que j'avais conçu pour un de mes frères.
J'ai cherché des scripts et on en trouvait déjà des kilomètres. Mais par soucis d'efficacité, je prenais quand même la peine d'en vérifier le fonctionnement en local. Donc j'avais installé un environnement de développement, à l'époque c'était EasyPHP, configuré en mode développeur, donc faisant tout afficher, pas juste les erreurs fatales, tous les warnings, toutes les notices, et ça pleuvait. J'en ai testé pas mal jusqu'au moment où je me suis dit « Ça va faire, là ! je vais me le programmer moi-même ». Et ça a commencé comme ça, j'ai pondu un petit forum relativement basique... qui fonctionne toujours. Le code est tout en procédural bien crade, du spaghetti comme on en faisait à l'époque, mais ça fonctionnait proprement.
Depuis, j'ai un tout petit peu évolué, et c'est devenu mon métier. Il est évident que maintenant, je programme en POO avec un framework maison, et je suis passé à PDO après le rachat de MySQL par Sun Microsystem et j'ai été convaincu du bien fondé de mon choix l'année suivante quand Oracle a racheté Sun Microsystem.
Mais te montrer des exemples de mon code ne t'aiderait pas des masses, c'est devenu assez compliqué, et si je le maitrise bien parce que je l'utilise tous les jours, l'expliquer ne serait pas pour autant une tâche facile. Mais pour PDO, je te dirais de ne pas te prendre la tête en anticipant sur des problèmes existentiels qui au final sont sans intérêt. Dis-toi que tu peux te créer une classe d'accès aux données basée sur PDO en y ajoutant des éléments permettant de switcher sur le bon driver selon le SGBDR utilisé, donc MySQL, Oracle, SQL Server, PostGreSQL, ou n'importe quel autre. Partant de là, tu as besoin de quoi au juste ? De quelques méthodes relativement peu nombreuses, schématiquement de base, il y en a deux :
- Une méthode de connexion recevant en paramètre les identifiants et quel driver utiliser;
- Une exécutant une requête SQL passée en paramètre et retournant le résultat;
Après, tu peux très bien affiner en séparant certaines méthodes pour réduire le code de chaque méthode. Mais l'idée générale reste que si tu fais un fetchAssoc avec ta classe, ça doit te retrourner la même chose que si tu le faisais directement avec mysql_fetch_assoc(). Donc le retour de l'exécution d'une requête SELECT doit être traité pour te retourner ce qui est attendu, en fonction d'un paramètre passé à la méthode par exemple.
Ensuite, au lieu d'utiliser les méthodes que tu utilisais jusqu'à maintenant avec mysql_etc.., tu appelles les mêmes méthodes de ta propre classe.
Ça, c'est la base, mais ensuite, tu peux évoluer en utilisant un Design Pattern qui s'apelle ActiveRecord, et pour faire simple, lorsque tu crées une ligne de données à insérer ou à modifier dans une table de ta base de données, tu peux le faire en objet, à partir d'une classe qui connait chaque colonne de la table en question, tu assignes les bonnes valeurs aux bonnes colonnes et tu as ensuite deux méthodes : sauvegarder() qui va enregistrer les données en faisant un UPDATE ou un INSERT selon que la valeur de la clé primaire est connue ou non, et une méthode supprimer() qui va faire un DELETE
Petite astuce que j'applique très volontier, tant en programmation que sur n'importe quoi d'aitre du reste : quand ça devient trop complexe, il faut faire un break et repartir des fondamentaux, revenir aux bases essentieles et arrêter de se torturer les méninges à essayer de comprendre un code tellement complexe que ça donnerait mal à la tête à un bloc de granit.
Et puis il y a peut-^tre autre chose que tu peux explorer : à la manière dont tu écris, je devine que tu es au Québec : il existe PHP QUebec qui organise périodiquement des évènements, je ne sais pas, je suis revenu du Québec en 2003 après y avoir passé 12 ans, j'ai un peu perdu de vue ce qui s'y passe. Mais tu pourrais rencontrer quelques amateurs passionnés pour échanger et discuter sur divers roblèmes de développement : en réfléchissant à plusieurs, on ouve toutes sortes de pistes pour avancer sur la manière de procéder de la façon la plus optimale.
Merci pour le partage Cyrano.
Y a matière à réflexions. Trop vrai pour les scripts, même pour les scripts comme Coppermine que j'ai testé et quelques autres.
Ce que je pensais faire, c'est de voir des alternatives pour le projet vu les délais qui passent. Et aussi, continuer en parallèle pour évoluer en PHP.
Content de pas me sentir trop seul. Ce n'est pas un domaine facile.
Je relirai à nouveau les messages de retour. Je suis du genre persévérant :-))
Je n'indique pas publiquement ma localisation mais si vous voyez mon IP, vous allez avoir une bonne idée d'où je suis :-)
C'est que les forums laissent des traces dans les engins de recherches. Google et Bing, ne sont pas mes amis. Eux avait des amis y a 10 ans mais plus maintenant avec leurs folies de tout savoir dans les rues de tout le monde.
Dan.
Pas de soucis.
Ici, c'est le seul forum où je contribue parce qu'il n'y a pas trop de monde et que je peux y passer un peu de temps, j'ai un peu lâché les autres parce que j'ai un boulot qui m'occupe déjà largement assez. Ceci dit, il y a une très bonne communauté sur PHPFrance et tu pourras y trouver pas mal de choses utiles
Donc n'hésite pas si tu as un soucis sur un point ou un autre, même si c'est au niveau conceptuel, décris ton idée et j'y apporterai mes observation s'il y a lieu d'en faire ;)
Je vais essayer ce framework:
http://simplemvcframework.com/
Si y a quelque chose de plus simple et qui sert d'exemple. Je suis preneur.
Bonjour,
Ou je travaille nous sommes plus de 5,000 programmeurs web, concepteur, architecte, etc.. et nous n'utilisons pas le MVC, peut-être quelques classes (POO, a peut près seulement une classe controlleur) et très peut de PDO aussi. (Nous avons plus de 10,000 sites en ligne).
Car notre énorme équipe de performance, après plusieurs tests, nous avons constaté que c'est quand même assez lent, nous fonctionnons en structure de couche, de cette manière nous avons seulement un endroit ou faire la modif (s'il y a lieu) de cette manière c'est ultra rapide (gain de 20 a 30 %). Surtout sur des tables de plusieurs millions d'enregistrements.
Car nous avons énormément de graphiques, de grosse recherche et surtout d'énorme requête, etc.. à effectuer. Nous avons essayé plusieurs Framework comme (YII, ZEND, etc..) mais cela n'en vaut pas la peine.
Salut lavm100,
intéressant retour :)
Ceci dit, j'ai tendance à penser (et à répéter accessoirement) que le terme de « framework » est souvent employé à tort et à travers, c'est devenu un terme fourre-tout où on retrouve aussi bien Zend-Framework et Symfony que Drupal voire d'autres CMS, bref, les définitions peuvent varier d'une personne à l'autre.
Pour ma part, je dis qu'un framework est un ensemble de codes qui gèrent l'architecture d'une application, en s'appuyant éventuellement sur des librairies et packages de librairies. Ça sous-entend que frameworks et librairies sont (ou plutôt doivent être) distincts et devraient se trouver dans des répertoires spécifiques.
Ensuite, le MVC, c'est là aussi souvent employé avec plus ou moins de pertinence en oubliant parfois l'idée générale qui sous-tend derrière : séparer les couches de façon à simplifier la maintenance et en permettant que la mise à jour d'un élément de la structure de code dans une des couches n'affecte pas les autres.
Ça peut donner lieu à des usines à gaz et je ne citerai pas de noms pour ne faire de peine à personne. Les courbes d'apprentissage sont en outre très souvent trop longues parce que le code est devenu tellement compliqué, alambiqué et surtout mal documenté que la prise en main est le plus souvent laborieuse. On finit par trouver des trucs de base pour avancer, mais paradoxalement, on sous-exploite les possibilités souvent voulues par le créateur de telle ou telle fonctionnalité tout simplement parce qu'en comprendre l'utilisation demande une gymnastique intellectuelle qui ferait passer des athlètes olympiques pour des paralytiques.
Et puis on oublie aussi trop souvent que le MVC est un Design Pattern composite, à tel point que certains comprennent bien l'idée de séparation des couches mais n'ont parfois aucune idée des Design-patterns qui doivent être mis en œuvre pour construire un MVC, même par des gens qui apparaissent comme des types costaux en la matière, ce qui donne des tutos parfois assez farfelus.
Il y a un corollaire intéressant à observer dans l'utilisation de frameworks-Usines-à-gaz : la nécessité de développer des outils d'optimisation pour accélérer l'exécution des applications, du genre Varnish et autres Caches d'OP-Code ou memcache. Je ne dis pas que ces outils sont une mauvaise idée, bien au contraire, mais c'est en même temps mettre la charrue avant les bœufs. Simplifier et optimiser les frameworks en premier lieu serait une bonne idée, du coup, les effets de ces outils d'optimisation seraient très probablement encore beaucoup plus intéressants.
Bonjour Cyrano,
Vous avez bien raison, mais malheureusement nous avons pas le temps ni les ressources et surtout l'argent pour faire soit des framework maison, ou tout découpé en plusieurs couches. Il est évident que notre méthode n'est pas parfaite (il peut y avoir du patchage) mais au moins nous avons un gain de temps d'exécution assez remarquable (surtout sur des tables de 150 millions de records).
C'est platte que tu ne puisses pas voir une bonne partie de nos sites (car ils sont en intranet) mais tu verrais, c'est assez remarquable, c'est quasi ment un excel, word, access, etc.. dans un même site. c'est époustouflant à voir...
Au plaisir !
Peut-être qu'un tutoriel pourrait être proposé sur le sujet.
Tous les tutoriels que j'ai sur le MVC utilisent soit pas l'orienté objet ou pas PDO. A vrai dire, des tutoriels qui utilise une architecture MVC avec des requêtes SQL PDO et Orienté Objet, y en a pas qui ne soient pas simple. On entends parler que des descriptifs et définitions, ou des sujet tellement complexe que ça ne nous donne pas raison d'aller dans le sens que propose PHP actuellement.
Dans le fond, ça été mon premier sujet de demander un tutoriel, un exemple concret ici.
:-)
Honnêtement, je n'ai pas le temps pour faire quelques chose de sérieux en ce moment, mais je crois qu'une petite explication de texte s'impose pour que aies un point de départ qui tienne la route.
Je te dirais pour commencer de ne pas mélanger les pommes et les oranges. Le MVC, c'est une architecture de programmation, quels que soient les choix de librairies que tu vas utiliser, et même quel que soit le langage de programmation que tu utilises. J'ajoute que parle de MVC en programmation procédurale est un non sens.
PDO, c'est autre chose : là, on parle d'accès aux données, ce dont tu peux avoir besoin dans ton application... ou pas, ça n'a aucune importance. Dans ton découpage pour construire un MVC, tu devrais avoir un répertoire de librairies, et parmi ces librairies, rien ne t'interdit d'en avoir un qui traite l'accès aux données en utilisant PDO.
Dans ton code métier ensuite, tu vas faire appel aux classes de ce package et les requêtes seront exécutées via PDO si le code du package est configuré comme tel. C'est cette notion de « code métier » qui t'échappe peut-être : il faut comprendre le code de ton application, c'est exclusivement celui qui est propre à cette application. Les librairies sont quant à elles génériques et ne doivent pas être au même endroit que le code métier mais dans un répertoire parallèle.
Lorsque pour une page donnée tu as besoin d'informations contenues dans ta base de données, ça veut dire que tu vas avoir besoin d'un objet qui va effectuer une connexion, d'un autre qui va utiliser cet objet de connexion pour exécuter des requêtes et retourner le résultat. Ton code métier va donc comporter des instanciations de classes qui se trouvent dans ton package d'accès aux données. Tu mettras ensuite le code des requêtes et les paramètres à utiliser et tu appelleras les méthodes appropriées en leur passant ces paramètres pour récupérer les informations voulues.
Ton code métier pourra être réparti en trois parties distinctes : les contrôleurs qui vont recevoir la requête HTTP de l'internaute, traduire cette requête pour définir de quel modèle ils ont besoin et définir ensuite les vues qui seront nécessaires. Le contrôleur récupèrera les informations des modèles, alimentera les vues et retournera le résultat à l'internaute.
Je précise aussi un détail important : dans ton code métier, il ne devrait y avoir aucun appel direct à une des méthodes de PDO, ces appels seront effectués dans ta librairie d'accès aux données qui en revanche te proposeront des méthodes pour le code métier. Si tu as par exemple un objet oDB, tu pourras par exemple utiliser une méthode $infos = $oDB->exec($requeteSql); ou encore quelque chose du genre $oDB->save($nomTable, $aInformations); où $aInformation serait un tableau associatif avec les noms des colonnes en clé et les valeurs à affecter en valeurs de colonne. Il faudrait bien entendu développer ces méthodes dans ta classe DB, mais en tout état de cause, l'idée générale reste la même : on sépare les librairies du code métier et si un jour tu dois remplacer PDO par autre chose, tu n'auras qu'à remplacer le package en veillant à ce que les méthodes proposées dans ton package PDO existent dans le nouveau package et donnent le même résultat : de cette façon, tu n'as qu'un nom de classe à changer dans l'instanciation et tu ne toucheras pas du tout à ton code métier.
Est-ce que tu visualises mieux le problème ?
Bonjour,
Dans l'fond ce que Dancom5 demande c'est un tutoriel complet sur le MVC, avec structure de répertoires, explication des classes complète, par exemple tu as des requêtes sql, tu récupères l'informations mais par la suite tu remplis des vecteurs avec les informations de ta requête et par exemple tu repasses tes vecteurs à du javascript..
Ou mettre les vecteurs ?? ou mettre le javascript ?? si tu as du json le mettre ou ??
Faire comme une suite logique de chacune des étapes.. Pas besoin d'écrire un roman, mais comme tu es bon pour vulgariser, si tu as du temps pour le faire, il serait gentil de le faire.
Pour Dancom5 et bien d'autre pourrait le lire et bien comprendre et partir sur des bases solides.
Merci !
Je confirme lavm100 et ça me plaît; merci!
Vous êtes bons tous les deux ;)
Et en même temps, vous ne réalisez même pas votre propre potentiel. lavm100, il y a plein de choses intéressantes dans ce que tu décris. J'y vois surtout des bonnes questions, questions auxquelles ils convient de déterminer des réponses.
Un truc à capter : mon but, ce n'est pas de filer un code tout fait prêt à l'emploi, c'est d'amener chacun à écrire son propre code, à trouver lui-même les réponses même si il faut de temps à autre lui donner des indications ou souligner une erreur. Il est illusoire de penser qu'un code complet vous apprendra quoi que ce soit. Il vous montrera certes bien des choses, mais je connais assez la psychologie pour savoir que ça rend aussi un peu paresseux : pourquoi se casser la tête à développer un truc quand un code complet aurait juste besoin d'être à peine ajusté pour être prêt à mon propre usage ?
Il faut vous lancer : mettez des réponses devant vos questions, et si ça coince quelque part, montrez moi votre code, j'y apporterai les remarques que ça pourra m'inspirer et éventuellement les indications en cas d'erreur.
Un tuto complet sur le MVC ? Il faudrait pour bien faire les choses, et les faire dans l'ordre, un premier tuto sur la POO, ensuite des tutos tout aussi complets sur les design patterns, ensuite seulement on pourrait parler de MVC. Ça ne ferait pas un roman, ou alors un roman de gare pour geek un peu disjoncté, mais ça ferait quand même beaucoup de choses à faire... pour moi surtout, et je manque de temps pour ça en ce moment. Si chacun de vous relit ce que j'ai répondu jusqu'à présent sur le sujet avec la plus grande attention, vous réaliserez peut-être que j'ai déjà indiqué pas mal d'éléments importants, peut-être basique voire élémentaires, mais si vous n'en tenez pas compte au départ, un tuto ne servira strictement à rien.
N'ayez donc pas peur de faire des erreurs, c'est en apprenant à les corriger qu'on acquiert l'expérience et l'autonomie. Ça demande certes un petit effort, mais je ne crois pas que ce soit à ce point insurmontable.
Donc, dancom5, pour en revenir à ton point de départ : commence, fais voir ce que tu as déjà fait en expliquant tes choix, pose des questions sur un point ou un autre, mais avance étape par étape. Il est possible, voire probable que certains choix ne seront pas judicieux, mais si je n'en ai pas connaissance, il me sera impossible de le deviner à tous les coups et donc d'anticiper suffisamment pour t'indiquer par avance quel élément éviter et quelle direction est correcte.
Enfin, je dirais ceci : gardez à l'esprit que cette approche dans l'apprentissage est le propre d'un vrai développer. Un bricoleur fera de la bidouille dans du CMS sans trop avancer et sans se prendre trop la tête, alors qu'un développeur est tout le temps confronté à des inconnues auxquelles il doit trouver une manière d'avancer, il doit créer, imaginer, concevoir, faire ses propres réponses. Les échanges peuvent permettre d'avancer, en réfléchissant à plusieurs et en confrontant les idées, on découvre les bonnes idées et chacun pourra détecter une erreur dans l'idée qu'un autre aura soumis, ou verra l'idée brillante dans la proposition d'un autre. On code seul, mais on réfléchit en groupe, ça facilite la vie : ça veut donc dire qu'il faut commencer par poser les bases du problème à résoudre, identifier les différents aspects de ce problème, les classer par ordre de priorité, et déterminer ensuite la manière de traiter chaque point dans le bon ordre. Par exemple : monter une application en MVC utilisant PDO, c'est commencer par découvrir qu'on va d'abord parler d'architecture logicielle, isoler chaque aspect du problème pour ne pas mélanger les pommes et les oranges, donc MVC pour l'architecture, PDO pour la partie librairies de code. Supposons que je parle de polymorphisme, de fabrique, d'observateur ou d'injection de dépendances, est-ce que ça te parle ? Ou bien est-ce encore du chinois pour toi ?
Bonjour Cyrano,
Merci pour ton dernier commentaire. Moi ce que je voulais dire c'est justement de ne pas mettre de code tout cuit dans le bec mais plus des explications sur POO et PDO et par la suite arriver à un modèle MVC.
Moi quand j'ai fini mes études en informatique il y a presque 30 ans déjà, disons que l'internet, le C et bien d'autres n'existait pas vraiment. J'ai commencé avec DOS 1.0, Cobol, ASSEMBLEUR, JCL, CLIST, PASCAL (et par la suite appris le Turbo Pascal). Mais disons que je viens du monde MAINFRAME mais surtout je suis un expert SAS (Statistical Analysis System). Oui il y a des macros, ods,... mais disons que le code fonctionne par bloc, procédure (ressemble un peu à du procédural en php).
Depuis quelques années disons que j'ai appris le PHP mais d'une manière (qui ressemble au codage SAS), alors pour moi le POO est disons comme un peu difficile à comprendre.
Juste en passant avec notre équipe de performance, nous avons fait des tests en PDO et MYSQLI et même PDO optimiser, mise en cache, etc... MYSQLI demeure encore plus rapide. Donc ma classe d'accès aux données en PHP passe par MYSQLI et non PDO.
Aussi la POO n'est pas obligatoire, ça dépend de quel genre de site tu fais, par exemple si tu fais un site avec navigation de page et seulement quelques accès aux données, tu peux le faire en procédural avec une vue gabarit et une vue accueil, un controlleur frontal, et une librairie qui contiendrait quelques API comme parse un fichier texte. Donc ta structure pourrait être du genre:
À la racine du site:
Model
Vue
Controlleur
Contenu
|--> images
|--> css
|--> js
Lib
index.php
.htaccess (si nécessaire)
À moins que ma structure ne soit pas bonne mais pour un petit site je crois que cela suffit.
Merci !
Pas de quoi lavm100.
Pour ma part, je suis autodidacte, je n'ai pas fait d'études supérieures, encore moins en informatique. Je me suis lancé dans le PHP par frustration en constatant la proportion effarante de code bogués écrit avec les genoux par des gorets. Un jour, je me suis dit « J'en ai marre, je vais les écrire moi-même », ce que j'ai fait, au début plus par distraction puisque j'avais une activité professionnelle qui n'avait absolument aucun lien avec l'informatique. Depuis, j'ai appris, je me suis perfectionné, jusqu'à être suffisamment capable pour gagner ma vie avec ça.
Pour ce qui est des performances, je ne suis pas certain que la comparaison PDO/MySQLi soit appropriée pour la simple raison que PDO est une couche d'abstraction permettant, schématiquement, de basculer d'un SGBD à l'autre sans devoir ré-écrire toutes les requêtes. Il est donc logique qu'il y ait une perte de performance dans la mesure où on introduit une couche intermédiaire de traitement entre PHP et le SGBD. J'ajouterais qu'il pourrait être intéressant de tester l'extension mysql_nd en lieu et place de mysqli.
Mais nous dérivons. dancom5 : si tu exposais la situation où tu en es ? As-tu abordé la construction de ton architecture ? Découpé tes répertoires pour y caser chaque élément à sa place sans que tout ça se chevauche, rendant la maintenance improblable ?
Tu pourrais exposer déjà ça en faisant un genre de croquis comme ceci :
- /
|- libraires/
| |- db/
| | |- mysql.php
| | |- pgsql.php
| | |- pdo.php
| | |- etc...
| |- formulaires/
| | |- processform.php
| | |- validation.php
| | |- etc...
| |- etc...
|- application/
| |- controleurs/
| |- modeles/
| |- vues/
| |- index.php
|- www/
| |- imgs/
| |- js/
| |- css/
| |- etc...
Je n'ai pas tout mis, juste une base de départ, et encore, surtout pour te donner un exemple de présentation dans ce forum.
Mais peut-être es-tu déjà plus loin ? Si tu ne dis rien, il sera difficile de te donner des indications pertinentes...
Merci lavm100 et Cyrano pour vos interventions.
Je comprends 'un peu' de tout mais je crois que c'est l'application pour faire un tout que j'ai de la misère à cerner.
Si je regarde la notion de l'objet comme créer une classe simple pour l'affichage, je suis capable. Si je fais une requête SQL PDO, je suis aussi capable. Si je fais un MVC très léger sur une base procédural, je comprends plus ou moins tant qu'on parle pas de contrôleur principal et routeur. Mais, si j'essaie ou tente de faire un tout, là, ça entre pas.
C'est l'idée de l'assemblage que je comprends pas.
Je suis habitué de faire les choses à la pièce comme quand j'ai appris sur le tas PHP et les commandes / fonctions.
Je comprends plus par des exemples et j'essaie de faire des variantes pour faire différentes choses. Genre, faire une requêtes pour faire un simple affichage etc.
J'ai déjà vu ce tutoriel y a un bout, et cela m'a sembler compliqué dans l'ensemble mais pris à la pièce, je comprends des trucs.
http://sdz.tdct.org/sdz/rogrammez-en-oriente-objet-en-php.html
Je crois que pour ce que je veux, c'est un tutoriel PAS à PAS qui me faudrait. Appliquer une affichage dans un pattern MVC.
Voilà. Je ne suis pas très avancé mais je suis un peu plus dedans qu'il y a un an, mettons.
Pour imaginer une application comme un tout, essaye de te représenter ça comme on décrirait une voiture : c'est composé d'un certain nombre d'éléments ayant chacun un rôle défini : tu as une carrosserie, un moteur, un habitacle, un réservoir de carburant, un tableau de bord assorti de divers instruments. Si tu mets le moteur dans l'habitacle, ça fonctionnera sans doute, mais le confort de l'utilisateur risque d'être des plus discutables, il faut donc le mettre à une place où il ne posera pas de problèmes au conducteur. Si tu installes le tableau de bord dans le coffre, le conducteur aura pas mal de difficultés à utiliser cette voiture.
Prends n'importe quelle marque de voiture, ils présentent tous des modèles différents, mais ils suivent tous un certain nombre de règles dans la construction de façon à ce que les utilisateurs y trouvent la facilité d'utilisation attendue.
Une application logicielle, en PHP ou dans n'importe quel autre langage, c'est un peu la même chose. C'est composé d'un certain nombre d'éléments. Il faut commencer par les identifier et ensuite il faut les répartir dans une arborescence de répertoires cohérente. Mon petit croquis de la réponse précédente, c'est un peu comme si j'avais griffonné rapidement un dessin de voiture, pas forcément une Rolls, mais au moins un modèle de base.
Que tu apprennes les choses une par une, c'est très bien, et c'est de toutes façon la méthode qui sera la plus efficace parce qu'essayer de toute apprendre en même temps, c'est risquer de mélanger plein de choses. Tu as quelques bases, mais ce qu'il faudrait tâcher de voir maintenant, c'est au moins l'idée générale du tout. Il faut commencer par définir à quoi va servir l'application. Quand un constructeur fabrique un modèle de voiture, il le destine à un usage particulier : utilitaire léger pour l'artisan, voiture familiale, petite voiture de tous les jours pour circuler en ville, véhicule de camping, ou véhicule de transport, voiture de course monoplace, etc... Ton application, c'est pareil : tu construis quoi ? Un site web, un blog, un site de e-commerce, une application de gestion en Intranet, autre chose ? Il faut au moins avoir une idée des grandes lignes du projet. En ayant cette base de départ, il sera beaucoup plus facile d'identifier de quoi tu vas avoir besoin. À ce stade, on va oublier le progiciel de gestion intégré multilingue, je te suggère de t'en tenir à un site web relativement basique. On ne construira pas une formule 1, mais un petit véhicule de loisir simple sera tout à fait envisageable. Tu as donc besoin de définir la carrosserie et y répartir les éléments : ton réservoir, c'est la base de données, ça, tu ne le construis pas toi-même, mais tu vas devoir y accéder, il te faudra des librairies, les éléments du moteur qui te permettront d'indiquer depuis les instruments du tableau de bord ce qui doit être exécuté.
Essaye de commencer par là : mets-toi ça sur une feuille de papier, décris ton application pour en identifier les morceaux. Ce sera ton point de départ, on ajoutera ce qui manque au fil du temps.
Ma stucture MVC de base, le contrôleur est l'index.php en racine.
Je ne suis pas certain pour le contrôleur.
Ce sont les objet extanciés que j'ai mis là.
Structure de base:
index.php
/MODEL/
connexion.php
model.php
/VIEW/
layout.php
template.php
style.css
index.php contient qui serait mon contrôleur:
<?php
require_once './model/model.php';
$oArtiste = new Artiste($cxn);
$ListerArtistes = $oArtiste->lister();
$artiste_id = (empty($_GET['artiste']))?'1':(int)$_GET['artiste'];
$AfficherArtistes = $oArtiste->afficher($artiste_id);
require './view/template.php';
connexion.php partie model:
<?php
$dnsh = "mysql:host=localhost;dbname=ptg";
$user = "root";
$pass = "";
$cxn = new PDO($dnsh, $user, $pass);
$cxn ->setAttribute(PDO::ATTR_PERSISTENT,true); //a le même effet qu'un singleton, sans les inconvénients
$cxn ->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
model.php partie model:
<?php
include './model/connexion.php';
class Artiste{
private $_conn;
public function __construct($cxn){
$this->_conn = $cxn;
}
public function lister(){
$stmt = $this->_conn->prepare('SELECT * FROM artistes');
$stmt->execute();
return $stmt->fetchAll(PDO::FETCH_OBJ);
}
public function afficher($id=null){
$stmt = $this->_conn->prepare('SELECT * FROM artistes WHERE id = :id');
$stmt->bindParam(':id', $id, PDO::PARAM_INT);
$stmt->execute();
return $stmt->fetchAll(PDO::FETCH_OBJ);
}
}
layout.php partie view:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<!--[if lt IE 9]><script src="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->
<title></title>
<meta name="keywords" content="" />
<meta name="description" content="" />
<link href="./view/style.css" rel="stylesheet">
</head>
<body>
<?php echo $content; ?>
</body>
</html>
template partie view:
<?php ob_start() ?>
<div class="wrapper">
<header class="header">
</header><!-- .header-->
<div class="middle">
<div class="minheight">
<div class="container">
<main class="content">
<?php
foreach($AfficherArtistes as $a_artiste) {
echo $a_artiste->id ." ". $a_artiste->prenom ." ". $a_artiste->nom;
}
?>
</main><!-- .content -->
</div><!-- .container-->
<aside class="left-sidebar">
<main class="content">
<?php
foreach($ListerArtistes as $l_artiste) {
echo "<a href='http://localhost/index.php?artiste=" . $l_artiste->id . "'>".$l_artiste->prenom ." ". $l_artiste->nom . "</a></br>";
}
?>
</main><!-- .content -->
</aside><!-- .left-sidebar -->
</div><!-- .minheight-->
</div><!-- .middle-->
<footer class="footer">
</footer><!-- .footer -->
</div><!-- .wrapper -->
<?php $content = ob_get_clean(); ?>
<?php include './view/layout.php'; ?>
Salut,
ça a l'air de tenir la route ton système : tu as bien avancé :)
Merci.
Je vais mettre tout ça dans un sous répertoire pour en faire un module et créer un contrôleur frontal que je devrai apprendre.
Comme j'ai deux requêtes, je suppose qu'il faudra créer deux contrôleurs pour séparer en couche ou sous-couche ?
Pas nécessairement : ce qui détermine la nécessité de créer un contrôleur ou non n'est pas le nombre de requêtes. À priori, un contrôleur correspond schématiquement à un « domaine » de l'application, ce sont ensuite les actions définies dans ce contrôleur qui définissent ce qui sera exécuté comme modèle et quelles vues seront utilisées.
Prenons un exemple : imagine un site de compagnie aérienne avec différentes pages : le calendrier des vols avec les destinations, les horaires d'arrivées, les horaires de départ : on pourrait logiquement regrouper les deux dernières dans un même domaine, sous un même contrôleur donc, mais avec deux actions, « arrivées » et « départs » : les requêtes ne seront pas tout à fait les mêmes et si l'affichage sera somme toute assez similaire, les données ne seront pas les mêmes, mais la même vue pourra être utilisée. En fin de compte, on a un un seul contrôleur, une seule vue, mais deux modèles, un pour les arrivées, un pour les départs.
Ceci dit, ça se traite au cas par cas, ça dépend vraiment de l'application et de la manière dont sont liées ou non les informations pour afficher telle ou telle page.
Sur mon même dernier codage, une personne m'a répondu ceci et je comprends pas super bien:
«
Ta classe Artiste est trop dépendante de l'utilisation de la BDD. Elle ne devrait pas utiliser directement des fonctions comme execute() ou fetchall() mais passer juste le sql à une fonction qui serait dans connexion.php et cette fonction lui renverrait les données (c'est-à-dire le résultat de fetchall()).
Et la fonction lister() devrait être statique : pas besoin d'instancier un artiste pour récupérer une liste d'artistes. Mais bien sûr en l'état, le fait qu'elle utilise une variable de classe (_conn) t'en empêche.
Sinon dans une appli il y a de multiples contrôleurs. Le fichier index.php que l'on met à la racine est plutôt le contrôleur frontal, c'est-à-dire le point d'entrée unique de l'appli. Ton fichier index.php ressemble plus à un contrôleur parmi d'autres qui serait dans un répertoire CONTROLLEURS.
»
Tu peux m'expliquer?
Mouais, ça aurait été bien qu'il fasse ce genre d'explication lui-même...
Pour le problème de dépendance à l'utilisation de la base, à ce stade, c'est à dire au stade de ton apprentissage et de la mise en œuvre d'une structure en MVC, c'est juste un peu plus compliqué. Disons pour faire court que ton architecture devrait comporter une partie « Librairies » dans laquelle on devrait trouver entre autres choses un packages DB ou quelque chose du genre pour la connexion à une base de données, l'exécution des requêtes et la récupération des résultats. Partant de là, ta classe artiste ne comporterait alors aucun appel à des fonctions propres à un driver de base de données mais plutôt des appels à des méthodes du package DB du style setRequete($sql) avec la requête SQL en paramètre, et encore getAll() qui retournerait l'ensemble des résultats trouvés ou bien d'autres méthodes qui appliqueraient des filtres. De cette manière, ta classe artiste ne serait pas dépendante d'un serveur de base de données en particulier, cet aspect étant géré au niveau du package DB.
Mon avis sur ce point : pas faux, mais dans l'immédiat, continue sur ta lancée et assimile déjà ça, tu amélioreras quand tu maitrisera bien ce niveau là.
Pour le contrôleur : un index.php dans une architecture MVC est effectivement la porte d'entrée par laquelle passent toutes les requêtes HTTP, quelle que soit la page appelée, et c'est du reste le plus souvent couplé avec de la ré-écriture d'URL. Derrière, on a alors un système de routage qui analyse l'url appelée pour en déterminer les différents paramètres, et donc quel contrôleur devra être mis en œuvre, quels modèles et quelles vues.
Ça sous-entend que dans ton framework existe une classe de routage qui fait cette analyse d'URL et qui sait où rediriger les requêtes. Ceci étant, si tu ne fais pas d'url-rewriting, tu pourrais avoir une page artiste.php qui serait le contrôleur correspondant à ta page artiste, le fichier index.php servant de porte d'entrée et appelant éventuellement par défaut artiste.php
On parle le plus souvent d'un contrôleur frontal et d'une collection de sous-contrôleurs. J'ajoute en général personnellement une notion moins couramment utilisée de gestion par « domaine » et de contrôleur de domaine, mais on risque de s'égarer dans des abstractions compliquées et de te larguer en cours de route, ce qui n'est certainement las le but de la manœuvre.
J'ai eu ceci comme explication:
«
Par exemple : http://bpesquet.developpez.com/tutor...re-mvc/#LV-B-1
Dans le dernier code source de ce paragraphe (Modele.php).
Pour ma 2ème remarque : on voit que la variable de classe $bdd devient une variable statique et peut donc être récupérée via la méthode statique getBdd(), qui se charge d'instancier $bdd si ce n'est pas déjà fait.
Pour ma 1ère remarque :
public function lister(){
return self::getConnection()->executerRequete('SELECT * FROM artistes');
}
avec executerRequete() qui renvoie le résultat de fetchall(). En récupérant un tableau, tu récupères quelque chose de totalement indépendant de la manière de récupérer les données.
Tu peux aussi t'inspirer de ceci : https://github.com/jpfuentes2/php-activerecord
»
Je suis allé voir, ça m'a pas permis de voir en quoi ça aurait été mieux.
Les explications tiennent la route effectivement.
L'idée d'avoir un système indépendant de la manière de récupérer les données est un des principes même du développement dit « industriel » où on peut avoir à développer des solutions pour toutes sortes de bases de données voire avec d'autres sources de données. Donc on finit par développer une gestion des données indépendant et ré-utilisable sur n'importe quelle application. Du coup, le code métier perd en taille aussi, une partie de ce code tétant déporté dans une librairie spécialisée.
Donc oui, c'est mieux, quoique peut-être un peu plus compliqué à assimiler d'entrée de jeu. En résumé, ça rejoint les principes de découplage et de séparation des couches du MVC. Dans le même temps, ça peut aboutir à un ensemble particulièrement compliqué à gérer et accessoirement on en arrive rapidement à de la programmation presque complètement orientée objet.
Si je décidais de n'utiliser que Mysql sans me soucier des autres drivers de BDD?
Rendre indépendant de ma base de donnée serait plus ou moins important?
Franchement, je ne vois pas comment je peux coder ça à partir de ce que j'ai déjà fait.
Quand j'étais petit, j'ouvrais tout ce que j'obtenais pour savoir comment c'était fait. Et j'ai appris à réparer des radios à transistors. Je me suis intéresser à savoir à quoi servait des condensateurs, etc. C'est la même chose pour l'origami, ou bien d'autres trucs de la vie. On regarde faire, et ensuite, on le fait. Les radios, ce n'est qu'un exemple.
Je comprends beaucoup par des exemples mais quand même pas trop compliqué. C'est comme ça que j'ai appris PHP via le manuel avec les exemples avec telle commande.
LE truc, c'est qu'on avance sur des concepts plus fins ou plus avancés alors que la base n'est pas forcément maitrisée et l'implémentation pas encore opérationnelle. C'est à mon avis la meilleure manière de se prendre une gamelle sévère. Fais un pas à la fois avec la base déjà acquise. À terme, tu pourras factoriser davantage en externalisant certains éléments et en les rendant plus génériques. Ce sera tout aussi formateur parce que tu risque d'être amené à le faire en réalisant qu'il y a par exemple un couplage trop fort entre deux éléments d'une classe. Te lancer dans des concepts théoriques et tenter de les assimiler avant de te heurter au problème sera à cet égard moins intéressant et moins évident à retenir.
Bonjour!
Je comprends plus le concept de MVC et aussi la notion de classe. Mais, depuis ma dernière présence ici, j'ai passé beaucoup de temps sur le sujet de "FrontController" de "router" et quelques autres aspects du genre.
Y a tellement de façons de faire, je n'arrive pas à faire pour que ça fasse avec mes bases à moi. Souvent les tutoriels qui se disent simples, commencent simple mais finissent plutôt très compliqués.
L'histoire du FrontController dans la pratique, ce n'est pas simple. J'ai pas trouvé d'exemple qui le soit. En plus, c'est souvent procédural.
Si j'avais un exemple que je pourrais adapter, je suis preneur. Ça me permettrait de tester, de raisonner, etc.
Bien à vous, Dan.
Salut,
dire que le MVC est simple est une aimable plaisanterie.
Le principe est simplissime, mais la mise en œuvre met généralement au jour des difficultés et une complexité tout à fait inattendue. Et crois-moi, je suis passé par là aussi sans trouver les tutos ni les aides recherchées. J'ai donc avancé à tâtons au fil du temps en faisant parfois des interprétations erronées. Aujourd'hui, je vis avec ça et ça fonctionne quand même, mais certains principes n'ont en fin de compte pas été abordés dans le bon sens.
Ce qui veut dire pour commencer que je ne connais pas de tuto montrant simplement comment construire un MVC complet et efficace.
Ensuite, je dirais que, par conséquent, il faut avancer en gardant à l'esprit les principes fondamentaux.
En PHP, on ne fait pratiquement jamais de full-objet comme en Java ou en C# par exemple, on passe obligatoirement par une partie en procédural. Le FrontControler, dans son principe de base, c'est ta page index.php qui reçoit toutes les requêtes HTTP de l'internaute. Ce fichier sera complètement en procédural, mais ne contiendra que relativement peu de code parce que ce qu'on y mettra principalement, ce sont des appels vers des classes du framework qui vont gérer le routage dans un premier temps (analyse de l'url demandée, paramètres envoyés ou non) et ensuite les sous-controler nécessaires : ces sous-controlers contiendront le code définissant quels modèles sont requis et quelles vues devront être utilisées.
Au fur et à mesure de ton montage, tu réalisera que certains éléments reviennent souvent et qu'une factorisation sera nécessaire, sous la forme d'éléments à intégrer dans ton framework : par exemple un système d'autoload pour tes classes, pourquoi pas une classe de registre, bref certains utilitaires. mais tu vas surtout réaliser toute l'importance de l'architecture de l'application en cours de construction : comment on découpe ça en répertoires et sous-répertoires pour s'y retrouver sans se noyer dans un capharnaüm ingérable.
On pourrait avancer en fonction de ton point de départ : décris déjà l'architecture de ton application, par exemple comme ceci :
/ index.php
|- Framework
|- Libs
|- Application
|- Public
|- CSS
|- imgs
|- JS
Indique ta propre architecture et essaye d'expliquer tes choix, on avancera sur cette base et j'apporterai mon avis et des suggestions s'il y a lieu.
