Discussion :

[kalimukti]

Bonjour,

Question philosophique: où placer la logique métier dans un modèle MVC (custom ou bien dans des framework comme Code Igniter, Zend...), dans le contrôleur ou le modèle ?

Si on m'avait posé cette question même il y a un mois, j'aurais sauté sur mon clavier et répondu : "Ben, dans le contrôleur voyons", fier de moi et légitimé par des phrases de tutos telles que :

"Le contrôleur est le chef d'orchestre de notre application. Il demande au modèle les données, les traite et appelle la vue qui utilisera ces données pour afficher la page.", tirée d'un célèbre MOOC php du web

Mais

La partie Modèle d'une architecture MVC encapsule la logique métier (« business logic ») ainsi que l'accès aux données. Il peut s'agir d'un ensemble de fonctions (Modèle procédural) ou de classes (Modèle orienté objet).

(tuto de développez)
Moi j'ai toujours pensé que c'est au contrôleur de transformer les données récupérées d'un modèle, de les "digérer" et de les envoyer à la vue/aux vues ensuite...

Mais en allant du côté des anglo-saxons, on trouve une toute autre approche (celle donnée par ce tuto de développez), qu'on peut lire aussi, par exemple dans cet excellent article:
résumé par:

Fat models, skinny controllers!
Keep as much business logic in the model as possible.
If you see your controller getting “fat”, consider offloading some of the logic to the relevant model (or else bad things will start happening!).
Models should not talk to the views directly (and vice versa).
Related models provide information to the controller via their association (relation).
It’s quite alright for the views to contain some logic, which deals with the view or presentation.

dont la traduction de la partie concernant la relation modèle/contrôleur pourrait donner:

des modèles bien gras, des contrôleurs maigres
Garder autant de logique métier que possible dans le modèle
Si vous voyez un contrôleur s'engraisser, réfléchissez à décharger une partie de la logique métier au modèle afférent (ou sinon des problèmes vont commencer à apparaître)
....

J'aimerai connaître votre point de vue / expérience sur le sujet... qu'est-ce qu'il y à gagner à glisser autant de logique métier que possible au modèle plutôt qu'au contrôleur ?

[ABCIWEB]

Salut,

En pratique moins tu spécialises le contrôleur général plus il aura la possibilité d'évoluer... On fait souvent différents niveaux de contrôleurs et les plus spécifiques pourront donc se trouver au plus près du modèle.

Après il y a moult déclinaisons du modèle MVC, donc pas étonnant que tu trouves des informations qui semblent contradictoires et cela dépend aussi du contexte.

[rawsrc]

Salut,

Le contrôleur doit vraiment être perçu comme le chef d'orchestre, c'est à dire qu'il doit savoir à quelle partie du modèle s'adresser pour effectuer une opération particulière, il doit être ensuite capable de disposer pleinement du résultat en provenance du modèle pour finir par savoir quoi en faire. Il peut même bosser un peu si nécessaire en mettant en forme les données pour les passer à d'autres parties du programme.
Il dirige les opérations sans les faire.

[Tsilefy]

Le contrôleur n'est pas un chef d'orchestre. C'est un aiguilleur. Un contrôleur reçoit des données entrantes (le plus souvent une requête HTTP), passe cette donnée entrante à un seul objet métier qui s'en occupe, cet objet retourne des données, et le contrôleur renvoie ces données à la vue sous forme de réponse HTTP (éventuellement en les transformant, par exemple en json, xml etc...). Rien de plus, rien de moins. Un contrôleur ne doit pas faire de traitement, ne doit pas utiliser plusieurs objet, rien. C'est un objet "bête", qui se contente juste de recevoir et d'envoyer.

On a une tendance à confondre Model et la représentation des objets métiers (ce qui explique entre autres pourquoi Doctrine a choisi "entity" et non model). Fat model est une fausse bonne idée si on se tient à la vision MVC traditionnelle du web, où model égale objet ORM: on applique le single responsibility principle aux contrôleurs, mais on transforme les models en God Objects.

Model représente toute ta partie métier, ton domain layer, qui comprends les entités, les répositories (si tu utilises Data Mapper), plus une infinité d'autres classes et interfaces et fonctions qui font un traitement métier. Fat model ne désigne donc pas une seule classe, mais un domain layer riche. C'est là que tout se passe. La clé, c'est que tu dois organiser ce domain layer pour que chaque responsabilité puisse avoir une porte d'entrée unique que le contrôleur appelle, et qui réalise toutes les opérations qu'on trouvait avant dans le contrôleur.

[Tsilefy]

Pour faire plus court, si tu vois un "if" (ou un "switch") dans un contrôleur, ce n'est pas bon.

[rawsrc]

@Tsilefy

Heu... c'est sacrément restrictif comme vision.
Quand tu sépares les contrôleurs en plusieurs couches tu t'en sors comment ?

Le contrôleur doit être perçu comme un point d'entrée et sortie de l'application, à ce titre il joue un rôle plus important que celui d'un simple passe-plats.

Je serai plus proche de la vision de ABCIWEB quand il dit :

On fait souvent différents niveaux de contrôleurs et les plus spécifiques pourront donc se trouver au plus près du modèle.

[kalimukti]

La clé, c'est que tu dois organiser ce domain layer pour que chaque responsabilité puisse avoir une porte d'entrée unique que le contrôleur appelle, et qui réalise toutes les opérations qu'on trouvait avant dans le contrôleur.
...
Pour faire plus court, si tu vois un "if" (ou un "switch") dans un contrôleur, ce n'est pas bon.

Merci à tous les 3 pour vos réponses... Elles confirment que j'ai bien fait de me/vous poser la question.
Tsilefy je comprends bien les principes de l'architecture dont tu parles.
L'idée derrière tout ça est donc d'avoir des contrôleurs évolutifs et maintenables, j'imagine.
J'ai juste du mal à comprendre qu'est-ce qu'on gagne à confier la logique métier (et donc les if, switch et autres...) aux couches des modèles plutôt qu'à celle des contrôleurs...

On a une tendance à confondre Model et la représentation des objets métiers

Ca veut direque la couche des modèles ne s'occupe pas particulièrement de l'accès aux données, et qu'elle se sert des objets métiers sans nécessairement les définir ?
Ca me donne l'impression, par rapport à mes habitudes de conception (contrôleur = logique métier + aiguillage // modèle = accès données + objets métiers) qu'il va s'agir pour moi de séparer mes contrôleurs en deux et que la partie logique, je peux la concevoir soit comme une sous-couche des contrôleurs (ce que je comprends de la réponse de ABCIWEB) soit comme une sur-couche de ce que j'ai l'habitude de concevoir comme des modèles... ça vous parle ?