Discussion :

[laurentSc]

Bonjour,

développant une application avec le pattern MVC, je me pose des questions sur la conception sur laquelle je suis parti : parmi les différentes classes, seules celles qui appartiennent au modèle possèdent des propriétés, mais jamais celles qui sont des contrôleurs ou des vues. Selon vous, est-ce un bon choix de conception ?

[laurentSc]

Pour aider à m'apporter votre point de vue, il me semble utile de donner mon raisonnement.

Tout d'abord, même si ça paraît évident, je ne l'avais pas dit : je code en POO.

Sinon, mon raisonnement vient du rôle des 3 composantes du pattern MVC :

contrôleur : rôle d'arbitre ; les contrôleurs ont pour responsabilité de traiter les demandes utilisateur, et font appel pour cela aux composantes du modèle et de la vue.

Modèle : gestion des données ; les classes du modèle ont pour responsabilité l'accès en lecture/écriture aux données et la manipulation de ces données.

Vue : affichage.

Au vue de cette répartition des responsabilités, il me semble logique que seules les classes du modèle possèdent des propriétés alors que les classes contrôleur ou vue ne possèdent que des méthodes.

Cette réflexion vous paraît-elle correcte ?

[Celira]

En général, les modèles sont des POPO (Plain Old Php Object), autrement dit, essentiellement composés d'attributs et d'accesseurs, plus le constructeur et éventuellement quelques méthodes utilitaires (par exemple, une méthode getAge() dans une classe Personne, qui calcule l'âge à partir de la propriété dateNaissance et de la date du jour)

Personnellement, j'ai aussi des classes de type Service, qui servent à manipuler les modèles. Par exemple, PersonneService va contenir une méthode creerPersonne qui prend une Personne en paramètre et l'enregistre en base. Ça permet d'alléger les contrôleurs, de centraliser le code non lié aux vues et mutualiser du code dont tu peux avoir besoin dans plusieurs controlleurs.
Une classe Service peut éventuellement avoir une propriété pour stocker la connexion à la base ou quelque du genre.
Une classe Utilitaire (par exemple, un parseur) peut avoir des propriétés ou non, en fonction du besoin


Les contrôleurs traitent les informations reçues (ex: formulaire), appellent les services et renvoient les informations pour l'affichage des vues. Je ne vois pas bien ce qu'on pourrait stocker dans une propriété

[laurentSc]

Merci pour ta réponse Celira. Je ne comprends la distinction que tu fais entre des classes Service et des classes Utilitaire.

des classes de type Service, qui servent à manipuler les modèles

Une classe Utilitaire (par exemple, un parseur)

Un parseur, ça manipule aussi des données, non ?

[grunk]

Tu te pose trop de question.

La présence ou non de propriété dans un classe n'est pas un choix de conception c'est inhérent au besoin du code.
Si tu n'as pas de données liées à l'instance de la classe à stocker , il n'y a pas de raison d'avoir de propriétés.