question sur tutoriel MVC

Version imprimable

04/06/2018, 11h07
Reelo

question sur tutoriel MVC

Bonjour,

Je me permet de reposter un message ici ,car je l'avais publié il y a 4 jours sur le forum MVC, et comme il n'y plus beaucoup de traffic (dernier message 2017 :( ), j'espère que quelqu'un pourra répondre à ma question.
j'étudie actuellement le tuto Evoluer vers une architecture MVC.
Tout va bien jusqu'au chapitre IV.
Mais ensuite, un truc m'échappe. En effet, au chapitre https://bpesquet.developpez.com/tuto...e-mvc/#LIV-B-2 on présente deux classes, Billet et Commentaire, avec leurs attributs et méthodes. Le problème est qu'on ne les utilise pas. Je ne vois aucune instanciation de ces classes dans dans la suite du tuto . Seules les donnée issues de la bdd sont utilisées. Est ce normal ?
En principe si j'ai bien compris l'avantage des objets c'est qu'une fois qu'on a récupérer les données, on créer nos objets qui serviront à l'application, et ensuite au besoin d'une modification d'une table on récupère les infos des objets pour les envoyer à la base n'est ce pas ? Dans ce cas, les objets servent bien 'd'interfaces' avec la bdd non?.
Si on doit utiliser les classes, pour créer des objets, dans quel dossier les mettre? dans le modèle ou le contrôleur ? et lequel doit les instancier ?
merci pour votre aide
04/06/2018, 13h13
rawsrc

Salut,

Citation:

Envoyé par Reelo

En principe si j'ai bien compris l'avantage des objets c'est qu'une fois qu'on a récupérer les données, on créer nos objets qui serviront à l'application, et ensuite au besoin d'une modification d'une table on récupère les infos des objets pour les envoyer à la base n'est ce pas ? Dans ce cas, les objets servent bien 'd'interfaces' avec la bdd non?.
Si on doit utiliser les classes, pour créer des objets, dans quel dossier les mettre? dans le modèle ou le contrôleur ? et lequel doit les instancier ?
merci pour votre aide

Les objets ne doivent pas être perçus uniquement comme des interfaces avec la base de données, ils sont bien plus : ils encapsulent la logique métier et cette dernière est généralement bien plus vaste que la base de données.
Les classes dites "métier" doivent être dans le dossier modèle. Le contrôleur n'est qu'un sas de filtrage, il vérifie ce qui est demandé et sait déterminer quelle partie du modèle serait en mesure de fournir une réponse à la requête d'entrée. Rien de plus.

Le contrôleur principal est instancié par l'application à chaque requête, ensuite ce dernier instancie (ou délègue l'instanciation) des classes métier en charge de la demande. Récupère le résultat du traitement et renvoie une réponse. Note qu'il peut y avoir des couches intermédiaires : contrôleur principal (Front controller), sous-contrôleur (Controller), modèle.
04/06/2018, 15h17
Celira
Je vais expliciter un peu :

Citation:

Envoyé par rawsrc

Les objets ne doivent pas être perçus uniquement comme des interfaces avec la base de données

En fait, en théorie, il est possible de changer de structure de stockage sans modifier la structure des objets : il faut "juste" adapter la récupération des données pour que les objets soient toujours remplis.

Citation:

Envoyé par rawsrc

ils encapsulent la logique métier et cette dernière est généralement bien plus vaste que la base de données.

Quelques exemples de ce qu'on peut trouver dans un objet métier :
- Dans une application de bibliothèque, tu peux avoir une classe Emprunt qui contient une liste de Livres et une date de retour. Sur cette classe Emprunt, tu peux avoir une méthode "estEnRetard" qui compare la date de retour théorique à la date du jour.
- Dans une application d'e-commerce : tu gères des clients et en fonction de leur âge, ils ont accès à différents tarifs. Pour cela, dans ta classe Client, tu vas créer une méthode "getProfilTarif" qui va te renvoyer "Enfant", "Adulte" ou "Senior" en fonction de l'âge calculé par rapport à la date de naissance et de la date du jour.
- Pour la gestion des droits : pour savoir si ton utilisateur a ou non le droit de faire quelque chose, tu peux avoir une méthode aPermission(<nom de la permission>) sur ta classe User.
Quelques exemples de ce qu'on ne doit pas trouver dans un objet métier :
- Pas de méthode "rechercherLivre" dans la classe Livre. Tu devrais avoir une classe LivreDao ou LivreManager ou un truc du genre, qui fait les accès à la base et qui va retourner une liste de Livre.
- Pas de propriété "age" dans la classe Client (et encore moins de colonne "age" en base de données) : l'âge change tous les jours, mieux vaut le calculer à la volée en fonction de la date de naissance.
- Pas de méthodes trop complexes : si tu as besoin d'utiliser des informations de plusieurs classes et de modifier des objets autres que celui dans lequel tu te trouves, il vaut mieux faire un service métier à part qui va faire les appels adéquats et les mises à jour.
04/06/2018, 17h52
Reelo

Merci pour vos précisions

J'ai peut être été vite en besogne en disant que les classes servaient d'interface entre la bdd et l'applicatif.
En fait, j'ai bien compris que les objets ne sont que des représentations de lignes présentes en base de données et que des classes dédiées doivent exister pour aider à leur gestion avec la bdd.
La chose déroutante dans le tuto, c' est que les classes servent à accéder à la bdd contrairement à ce que Celira a dit dans son post. A un moment donné il faut bien les instancier ces satanés Objets pour pouvoir s'en servir :mrgreen:
Donc, est ce que ça veut dire que pour bien faire, il faudrait mettre les classes Commentaire et Billet dans un dossier , Entités par ex, dans modele et créer d'autre classes dans ce même dossier modele qui managent ces classes ? sans parler des contrôleurs à mettre dans controleur bien sûr ! :)
05/06/2018, 10h17
Celira

En premier lieu, pour moi, les classes du tuto sont mal nommées : La classe Modele pourrait s'appeler quelque chose comme BddManager ou Dao (ou AbstractDao si c'est une classe Abstraite), Billet serait alors BilletManager ou BilletDao, et ainsi de suite. Tu pourrais ainsi avoir les classes Billet et compagnie, qui seraient les vrais objets, et qui seraient instanciés à l'intérieur du DAO.

Ensuite, les Dao sont instanciés dans le Controlleur, vu que c'est lui qui les utilise.
05/06/2018, 11h21
Reelo

Humm pas simple tout ça .:(

En tous cas merci Celira pour ton aide . C'est vrai que le tuto a peut être cherché à trop vouloir simplifier le MVC et que montrer comment utiliser les classes métier et où les placer dans l'arborescence aurait été un plus non négligeable.Ceci dit ça reste quand même clair dans la démarche.
Je vais continuer comme ça pour le moment et je le referais en renommant les fichiers comme tu l'as expliqué et en utilisant les deux classes proposées.
Je l'aurais un jour, je l'aurais ... ! :mouarf:
12/06/2018, 10h22
CinePhil

Citation:

Envoyé par rawsrc

Les classes dites "métier" doivent être dans le dossier modèle. Le contrôleur n'est qu'un sas de filtrage

Ça me fait plaisir de lire ça !
Je me suis fritté avec le formateur de mon stage PHP Objet la semaine dernière à ce propos.

Par contre...

Citation:

Envoyé par Celira

En premier lieu, pour moi, les classes du tuto sont mal nommées : La classe Modele pourrait s'appeler quelque chose comme BddManager ou Dao (ou AbstractDao si c'est une classe Abstraite), Billet serait alors BilletManager ou BilletDao, et ainsi de suite. Tu pourrais ainsi avoir les classes Billet et compagnie, qui seraient les vrais objets, et qui seraient instanciés à l'intérieur du DAO.

Ensuite, les Dao sont instanciés dans le Controlleur, vu que c'est lui qui les utilise.

1) Tu mets les classes DAO et les classes Métier dans le modèle ou tu les sépares ?
2) Quel est l'intérêt de séparer le DAO de la classe métier ? (et ne me parle pas des Outils Réellement Merdiques ! :mrgreen: )
3) Je pourrais comprendre qu'une classe DAO soit en étroite interaction avec une table ou une vue de la BDD et qu'elle puisse être utilisée par plusieurs classes métier ; ce qui justifierait la séparation. Mais alors, ce serait plutôt la classe métier qui instancierait la classe DAO et pas l'inverse comme tu l'as écrit, non ?
12/06/2018, 11h12
Celira

Hum... pour la petite histoire, j'essaie de transposer les concepts que j'utilise en Java sur un projet PHP, sachant que mes projets Java utilisent des frameworks et donc qu'il faut démêler ce qui est imposé par le framework de ce qui ne l'est pas.

Tout ce que je dis ensuite est mon avis personnel, les noms utilisés pour décrire les concepts sont ceux que j'utilise, pas forcément les noms officiels des dits concepts

Je sépare les DAO des métiers, parce que le métier n'est pas censé être dépendant de la solution de stockage. Si la semaine prochaine je décide de stocker mes données avec MySQL, MongoDb ou dans des fichiers XML écrits à l'envers, le métier ne change pas. Les utilisateurs sont toujours des utilisateurs, ils ont toujours une fonction de login et ainsi de suite.

Ensuite pour moi, il y a 2 niveaux d'objets métiers : les entités (qui représentent des choses) et les services (qui représentent des actions entre les entités). C'est le service qui instancie le DAO et qui lui envoie les entités.

Prenons l'exemple d'une application bancaire.
On va avoir une entité Client (nom, prénom, identifiant...) et une entité Compte (numéro de compte, type de compte, solde...), un client pouvant avoir plusieurs comptes.
Si on veut gérer un transfert d'argent, on ne peut pas mettre la fonction dans Compte, parce qu'un transfert manipule deux comptes : un en débit et un en crédit. On va donc faire un TransfertService , qui va retirer l'argent du compte 1 et l'ajouter sur le compte 2, en passant par la DAO pour manipuler les données en base.

Citation:

Envoyé par CinePhil

Ça me fait plaisir de lire ça !
Je me suis fritté avec le formateur de mon stage PHP Objet la semaine dernière à ce propos.

De temps en temps, les profs/formateurs/assimilés ne sont pas à la pointe de la technologie et ont des principes et/ou des préjugés qui font hurler les dev pros.
Je me souviens d'avoir aidé un newbie sur le forum dont le prof/formateur/assimilé ne connaissait pas PDO, il y a de ça 2 ou 3 ans (donc en 2015 ou 2016). Quand on sait que j'ai travaillé sur une appli avec PDO en 2009, il y a de quoi s'inquiéter sur la qualité de certaines formations.