Salut,
Je développe une application web actuellement et puisque le web n'est pas ma spécialité, je viens demander de l'aide ici
En fait c'est tout bête, je base mon application sur le pattern MVC qui, de ce que j'en ai entendu, aide à l'organisation du projet pour mieux s'y retrouver lorsqu'on accumule des dizaines de fichiers, et ne voulant pas faire de connerie, je viens demander confirmation ici
Imaginons que j'ai trois pages : index.php - contact.php - connection.php
Dans l'arborescence de mon appli, dois-je créer trois dossiers (Model - View - Controller) et, pour chaque page que je veux faire, leur créer trois fichiers PHP (un pour le modèle, un pour la vue, un pour le contrôleur) ? Ce qui donnerait :
index.php - indexView.php - indexModel.php
contact.php - contactView.php - contactModel.php
connection.php - connectionView.php - connectionModel.php
Ai-je bon ? Je dois faire ça pour chaque nouvelle page du site web ?
Par ailleurs, si je veux créer un objet qui crée des formulaires et les gère, y a-t-il une convention de où mettre cet objet ? Dans un dossier avec un nom particulier ?
Merci !
Je ne connais pas php mais pour utiliser le pattern mvc tu n'as pas forcément 1 controller/model par page.
Ton controller tu peux le partager entre plusieurs pages si celle ci font partie du même domaine, du genre si ti tu as une page d'affichage des contacts, une autre d'édition, une autre de suppression, tu vas crée un controller commun pour ces 3 pages, et tu aura aussi peut être un seul modèle Contact, étant donné que les infos sont les mêmes à chaque fois.
Le 19 février 2021 à 19:10:38 boucif a écrit :
Je ne connais pas php mais pour utiliser le pattern mvc tu n'as pas forcément 1 controller/model par page.
Ton controller tu peux le partager entre plusieurs pages si celle ci font partie du même domaine, du genre si ti tu as une page d'affichage des contacts, une autre d'édition, une autre de suppression, tu vas crée un controller commun pour ces 3 pages, et tu aura aussi peut être un seul modèle Contact, étant donné que les infos sont les mêmes à chaque fois.
Ah oui je vois, ça demande quand même de réfléchir plutôt que de créer bêtement trois fichiers PHP à chaque "nouvelle page" du site
J'avais oublié de prendre en compte le contrôleur frontal aussi, du coup au final, je pense qu'on se retrouve avec peu de fichiers contrôleurs, un nombre moyen de fichiers modèles, et beaucoup de fichiers vue
Oui, l'important en MVC c'est le "flux", t'es sur la home tu vas consulter les contacts, ta home appel ton controlleur contact et la méthode qui affiche la liste des contact, cette méthode va récupérer ta liste de contact et renvoyer ta vue ListeContact avec tes datas...
Tu vas passer à chaque fois par un controlleur pour chaque interaction avec le serveur, et c'est lui qui se charge de remonter les données et d'afficher la bonne vue...
Le 19 février 2021 à 19:00:21 GameWaifus2 a écrit :
Salut,Je développe une application web actuellement et puisque le web n'est pas ma spécialité, je viens demander de l'aide ici
En fait c'est tout bête, je base mon application sur le pattern MVC qui, de ce que j'en ai entendu, aide à l'organisation du projet pour mieux s'y retrouver lorsqu'on accumule des dizaines de fichiers, et ne voulant pas faire de connerie, je viens demander confirmation iciImaginons que j'ai trois pages : index.php - contact.php - connection.php
Dans l'arborescence de mon appli, dois-je créer trois dossiers (Model - View - Controller) et, pour chaque page que je veux faire, leur créer trois fichiers PHP (un pour le modèle, un pour la vue, un pour le contrôleur) ? Ce qui donnerait :
index.php - indexView.php - indexModel.php
contact.php - contactView.php - contactModel.php
connection.php - connectionView.php - connectionModel.phpAi-je bon ? Je dois faire ça pour chaque nouvelle page du site web ?
Par ailleurs, si je veux créer un objet qui crée des formulaires et les gère, y a-t-il une convention de où mettre cet objet ? Dans un dossier avec un nom particulier ?
Merci !
Apprends symfony
il te faut un index.php
la tu vas créer toutes tes routes et templating (Twig ou php pure ou autres)
Ensuite un dossier controller oui un controller pas typologie de page c'est bien,
un dossier Model ou Entité avec les object de ton app (User, Facture, Panier)
un dossier view : avec un layout et tes pages comme ça tes pages ont juste leurs codes propres.
En gros dans le controller tu le codes métier et le call au moteur de templating le render
Ensuite tu peux créer un dossier form
ainsi de suite.
Mais go faire un tuto Symfony tu auras déja tous ça de fais (routing , templating ...)
Le 19 février 2021 à 19:47:39 VinkingBanni a écrit :
Le 19 février 2021 à 19:00:21 GameWaifus2 a écrit :
Salut,Je développe une application web actuellement et puisque le web n'est pas ma spécialité, je viens demander de l'aide ici
En fait c'est tout bête, je base mon application sur le pattern MVC qui, de ce que j'en ai entendu, aide à l'organisation du projet pour mieux s'y retrouver lorsqu'on accumule des dizaines de fichiers, et ne voulant pas faire de connerie, je viens demander confirmation iciImaginons que j'ai trois pages : index.php - contact.php - connection.php
Dans l'arborescence de mon appli, dois-je créer trois dossiers (Model - View - Controller) et, pour chaque page que je veux faire, leur créer trois fichiers PHP (un pour le modèle, un pour la vue, un pour le contrôleur) ? Ce qui donnerait :
index.php - indexView.php - indexModel.php
contact.php - contactView.php - contactModel.php
connection.php - connectionView.php - connectionModel.phpAi-je bon ? Je dois faire ça pour chaque nouvelle page du site web ?
Par ailleurs, si je veux créer un objet qui crée des formulaires et les gère, y a-t-il une convention de où mettre cet objet ? Dans un dossier avec un nom particulier ?
Merci !
Apprends symfony
il te faut un index.php
la tu vas créer toutes tes routes et templating (Twig ou php pure ou autres)Ensuite un dossier controller oui un controller pas typologie de page c'est bien,
un dossier Model ou Entité avec les object de ton app (User, Facture, Panier)
un dossier view : avec un layout et tes pages comme ça tes pages ont juste leurs codes propres.En gros dans le controller tu le codes métier et le call au moteur de templating le render
Ensuite tu peux créer un dossier form
ainsi de suite.Mais go faire un tuto Symfony tu auras déja tous ça de fais (routing , templating ...)
C'est bien reçu pour Symfony, je viens de commencer mais j'avais déjà une question à ce sujet...
Mon projet est une application web, c'est une sorte de CMS en fait, et dans l'idéal ce sera destiné à être installé sur des serveurs web un peu comme WordPress, donc ce n'est pas vraiment un site web que j'hébergerai moi-même. Est-ce que Symfony convient quand même pour ce genre de chose ?
oui, ça conviens à tous les projets en php
tu sais ya deja des tonne de cms en symfony ou qui utilise symfony
EZpublish, drupal, grav ...
Je suis pas vraiment sûr que apprendre Symfony pour comprendre le pattern MVC est important ici.
D'autant plus si c'est une application simple que tu veux développer, ça me parait limite overkill à mon avis.
Même si Symfony reste un framework MVC, tu vas devoir te coltiner tout un tas d'informations propre au framework ce qui alourdit la charge d'apprentissage, et j'imagine que tu ne sera pas à même de sélectionner ce qui t’intéresse, comprendre le pattern et faire ton appli en MVC.
Sinon par convention je te suggère de nommer tes classes et tes fichiers comme suit
( dans leurs dossiers respectifs évidemment )
ContactController.php - ContactView.php - ContactModel.php
Sinon après t'es libre de gérer ton projet comme tu l'entends, tant que le tout reste consistant et cohérent tout au long du projet, ce n'est pas une conception rigide bien au contraire, en témoigne le nombre de discussions sur les forums de devs.
En gros te tracasses pas à faire des abstractions et à over-engineerer le bordel si ton application est simple, regroupe le tout en modules qui te semblent logiques.
Y a sûrement des adorateurs de fat-models lean-controllers "skinny controllers" ici présent, je suppose que tu peux tout à fait faire des "fat-controller" et regrouper ta logique d'appli dessus si tu tu t'y es plus à l'aise.
Libre à chacun d'organiser son code comme il l'entends, surtout si tu ne suis pas les directives d'un framework en particulier.
et beaucoup de fichiers vue
Dans l'idéal et comme mentionné par VinkingBanni tu peux utiliser un moteur de template comme Twig pour te simplifier la tâche, avec un fichier layout qui te servira de base commune pour ton site, et des blocks que tu injectera sur chaque vues selon tes besoins.
Après les tutos Symfony sont bons, si tu bloques sur quelque chose gardes la doc sous la main elle te servira, mais de là à conseiller de l'apprendre et l'intégrer pour un truc visiblement assez simple ( tu débutes si j'ai bien compris ... ) autant te jeter dans le bain et bien comprendre le pattern sans se faire chier avec un framework, c'est mille fois plus formateur à mon sens.
Ca ne reste que mon humble mon avis.
Sinon pour finir mon message, jette un oeil si t'es curieux a un pattern qui est de plus en plus courant en PHP, l'ADR ( Action Domain Responder ), c'est une toute autre façon de procéder mais peut être qu'elle te sied mieux.
Pour aller plus loin sur le MVC je te conseille de lire / scroller à ta guise ce tutoriel :
https://bpesquet.developpez.com/tutoriels/php/evoluer-architecture-mvc/#LIV-C
Tu verras la structure " basique " d'un projet de blog tout simple en MVC, le tutoriel n'est pas jeune, mais il en reste pas moins très instructif.
J'imagine que c'est plus parlant qu'un gros pavé comme je viens de le faire.
Je suis pas vraiment sûr que apprendre Symfony pour comprendre le pattern MVC est important ici.
Justement, c'est un des meilleurs exemples d'abstraction.
Non, c'est pas overkill, Symfony a bien évolué est bien plus léger.
tu vas devoir te coltiner tout un tas d'informations propre au framework
Non, ya rien de spécifique, c'est juste du php
Enfaite pour utiliser Symfony et son pattern MVC tu n'as pas besoin de maîtriser PHP, car c'est lui qui va gérer toutes l'inclusion (routing, annotation , etc...)
Contrairement au fait que si tu dois faire ton propre système tu vas devoir acquérir toutes ces connaissances.
Gérer ta requête HTTP...
Sinon après t'es libre de gérer ton projet comme tu l'entends, tant que le tout reste consistant et cohérent tout au long du projet, ce n'est pas une conception rigide...
Non, encore une fois, sinon autant ne pas utiliser de pattern. Le but est de rendre une application bien plus lisible et organisé
Si tu commences à faire des pâtés de code dans un contrôleur ça ne va pas...
Limite tans ton controller index par exemple tu dois juste avoir une fonction simple du style:
public function index () {
/* je lis les données depuis le model associer */
return render('index.htm.twigl', $datas); /* index.php pour le templating php*/
}
Genre dans 10 ans, tu ne te diras pas qu'est-ce que j'ai foutu.
Sinon pour finir mon message, jette un oeil si t'es curieux a un pattern qui est de plus en plus courant en PHP, l'ADR ( Action Domain Responder ), c'est une toute autre façon de procéder mais peut être qu'elle te sied mieux.
Euh, je suis allé voir j'ai rien compris. Fais tu MVC c'est plus simple surtout pour un projet comme un petit CMS pour un blog perso. compliquer pour pas grand choses.
Et si tu veux performer tu peux aller du côté des micro-services et de l'encapsulation :
https://fr.wikipedia.org/wiki/Architecture_orient%C3%A9e_services
Tu divises en ton code en services, par exemple moi récemment j'ai fait un service getDatas
.
Ce service a pour but de taper les repositories et donc la couche modèle du pattern et de retourner les données formater ou non.
Chaque contrôleur appelle getDatas pour faire leurs rendus (moi je fais du json, mais ça marche pour du html).
En gros si j'ai un problème de données, c'est getDatas
le fautif.
Pareille pour les formulaires j'ai un service form, je luis place la class à instancier et luis vas me faire le formulaire, je suis sur de l'api, donc il fait aussi le traitement. Pareille si j'ai un problème d'enregistrement c'est mon service que je dois modifier.
C'est compliquer à mettre en place, mais beaucoup d'avantage. Ton application est subdivisée en services indépendants leurs rôles est vraiment bien défini. Le mélange de fonction est donc impossible et le code doit être forcément généraliste.
Par exemple pour get data pour différents besoins je luis passe la méthode du répository a utilisé (avec doctrine c'est findBy
par défaut) et aussi si jeux une collection d'objets ou un tableau. Si j'ai besoins de la collection pour faire un traitement spécifique dans le contrôleur par exemple.
Enfaite soit tu te dis je prends l'options la plus complexe (mais surement la plus formatrice et chronophage) qui va mettre à mal ta motivation et ta détermination, donc faire ton propre pattern MVC / framework.
Soit tu prends la methods douce et tu décides d'explorer Symfony.
https://github.com/symfony/demo/blob/main/public/index.php
https://github.com/symfony/demo/blob/main/src/Kernel.php
etc ...
Marav a raison hein, se lancer dans un framework comme symfony pour commencer c'est totalement sous optimal en terme d'apprentissage. L'aspect MVC de symfony c'est vraiment une trivialité du framework, si le mec a pas compris le pattern il fonce juste droit dans le mur.
Après il comprendra hein, mais il va perdre énormément de temps là où il pourrait juste, bah, faire une application MVC toute simple et ce faisant comprendre l'intérêt des ajouts d'un framework dans un second temps ?
Le 20 février 2021 à 16:54:51 galoiseries a écrit :
Marav a raison hein, se lancer dans un framework comme symfony pour commencer c'est totalement sous optimal en terme d'apprentissage. L'aspect MVC de symfony c'est vraiment une trivialité du framework, si le mec a pas compris le pattern il fonce juste droit dans le mur.Après il comprendra hein, mais il va perdre énormément de temps là où il pourrait juste, bah, faire une application MVC toute simple et ce faisant comprendre l'intérêt des ajouts d'un framework dans un second temps ?
J'explique pourquoi enfaite non. Tu as bien plus à apprendre si tu fais toi-même.
Après ci tu fais des contrôleurs en mode index.php, oui, mais c'est pas vraiment optimal c'est limite cracher à la gueule du pattern
Y'a pas de bonnes réponses, mais si c'est pour un projet pro ou futur pro -> go Symfony
Si c'est pour apprendre et le fun : go from scratch ! et dans ce cas pourquoi pas aussi voir le pattern proposer par Marav