Dans MVC, est-il considéré comme une bonne pratique d'avoir des fonctions privées sans action dans une classe de contrôleur?

Parfois, les fonctions d'action dans la classe de contrôleur peuvent devenir énormes et désagréables, avec de nombreuses lignes de code pour contrôler simplement le flux de données du modèle vers la vue. À un moment donné, ces énormes fonctions perdent complètement la trace des principes de base d'un bon code, c'est-à-dire ne font qu'une chose, sont petites, lisibles et gérables, etc.

Serait-il considéré comme une bonne pratique de diviser ces énormes fonctions d'action en fonctions privées plus petites dans la classe de contrôleur ou le besoin d'une telle optimisation signifie-t-il que nous devrions plutôt les ajouter dans le modèle?

Je voterais pour que les petites fonctions soient privées dans le contrôleur afin qu'elles soient relatives à l'action, mais j'ai entendu des arguments selon lesquels le contrôleur devrait de préférence être simple tandis que le modèle peut devenir énorme et grumeleux; et se demandait simplement laquelle serait la méthode la plus préférée.

Ce n'est peut-être pas la meilleure analogie, mais pensez au contrôleur de la même manière que vous penseriez à une toile d'araignée. Son seul travail consiste à attraper les mouches (demandes) pour que l'araignée (couches sous-jacentes) digère. La toile peut attraper et contenir des mouches plus ou moins grandes (modèles). Le rôle d'une toile d'araignée n'est pas de digérer la proie, bien qu'elle puisse être utilisée à cette fin. Plus la toile est fine et propre, plus l'araignée gagne facilement sa vie.

Vous pouvez appliquer un peu la même logique à votre application MVC. Les fonctions énormes et désagréables que vous décrivez sont le comportement le plus probable du modèle et elles devraient appartenir au modèle (notez que le modèle n'est pas seulement l'objet affiché dans la vue). Si le comportement du modèle change, c'est le modèle qui doit être modifié et non le contrôleur qui le gère.

De plus, les conserver en tant que méthodes privées dans le contrôleur ne ferait que l'encombrer et le rendre difficile à maintenir. Cela fait également place à une mauvaise habitude, car d'autres personnes impliquées dans le développement seraient tentées de faire de même, car elles l'ont déjà vu dans le projet.

La meilleure réponse que je puisse donner est de citer le grand livre de Robert Martin, "Clean Code" que je recommande fortement à toute personne intéressée par le sujet:

La première règle des fonctions est qu'elles doivent être petites. La deuxième règle est qu'ils doivent être plus petits que cela.

Je ne peux pas le dire mieux. Une autre grande citation du même livre s'applique:

Les fonctions devraient faire une chose. Ils devraient bien le faire. Ils devraient le faire seulement.

Lorsque vous divisez votre code en plusieurs fonctions, vous êtes obligé de donner à ces fonctions des noms significatifs qui peuvent améliorer considérablement la lisibilité de votre code. Inutile de dire que toutes les fonctions qui ne sont pas destinées à être utilisées en dehors de la classe doivent être privées, vous pouvez donc facilement réutiliser votre code via l'héritage.

Si votre contrôleur a maintenant trop de fonctions, c'est un signe qu'il en fait probablement trop. Ensuite, vous pouvez le diviser en plusieurs morceaux indépendants ou essayer de déplacer certaines fonctions vers des modèles comme mentionné dans l'autre réponse. De plus, si vous suivez la saveur MVC non classique, où les vues sont autorisées à avoir une certaine logique, vous pouvez y placer certaines de vos fonctions chaque fois que cela vous convient.

Dans MVC, j'essaie de m'assurer que mon contrôleur est aussi "mince" que possible et que mes modèles sont aussi stupides que possible.

Les fonctions logiques et d'assistance nécessaires sont placées dans des classes d'assistance autonomes distinctes. Cela facilite également mes tests (vous testez .. n'est-ce pas ??: D) Le test des contrôleurs est notoirement difficile, chaque fois que vous essayez de créer une instance d'un contrôleur pour tester, vous devez penser au contexte HTTP et simuler http ceci et cela, et c'est une douleur, mais c'est une douleur exprès. Vous avez besoin de tout cela parce qu'un contrôleur est si étroitement lié à HTTP et au Web. C'est le point d'entrée de votre application Web.

Les fonctions logiques et d'assistance n'ont rien à voir avec le Web. Ils sont entièrement indépendants de l'environnement (ou ils devraient l'être). Cela seul devrait vous dire qu'ils n'appartiennent pas ensemble au même endroit. De plus, si vous liez si étroitement la logique de toutes vos applications au Web ou à une implémentation Web particulière, vous ne pourrez jamais l'emporter avec vous.

Nous avons développé notre site MVC avec toutes nos entités de base de données (pas nos modèles mvc, nos entités db réelles), notre stockage, nos classes d'assistance et notre logique en dll autonomes autonomes. Nous n'avons eu qu'un seul site Web, mais nous l'avons quand même fait comme ça.

Il y a quelques mois, on nous a demandé de créer quelques applications de bureau liées à quelques-uns de nos systèmes marginaux. Cela a été facilement fait car tout notre code testé pouvait facilement être réutilisé. Si nous avions inséré notre code dans notre projet Web ou inséré dans nos contrôleurs, nous n'aurions jamais pu le faire.

À côté de Dmitri Zaitsev et de grandes réponses spateman, je ne sais pas si ce qui suit est également valable pour PHP: Vous devriez essayer d'éviter les méthodes privées en raison du manque de possibilités de test automatisé.

Oui, vous pouvez également utiliser la métaprogrammation ou l'injection de dépendance pour tester des méthodes privées, mais vous ne devriez pas le faire car cela a un impact énorme sur la lisibilité de votre code.

Rappelez-vous toujours le principe KISS: restez simple, stupide.