Quels sont les avantages et les inconvénients de l'utilisation du pattern Front Controller?

Question

Actuellement, je conçois tous mes sites Web avec un fichier pour chaque page, puis j'inclus des éléments communs comme l'en-tête, le pied de page et ainsi de suite. Cependant, j'ai remarqué que de nombreux frameworks et CMS utilisent le pattern Front Controller.

Quels sont les avantages et les inconvénients de l'utilisation d'un contrôleur frontal? Le modèle est-il simplement utilisé dans les frameworks et les CMS car on ne sait pas quelles pages existeront dans le système final?

Answer 1

Srikanth a une bonne réponse. Je voudrais développer sur l'alternative, cependant. Supposons que vous ayez cette hiérarchie simple URL:

 
/gallery 
/blog 
/admin/login 
/admin/newpost 

Si cela est mis en œuvre avec les contrôleurs de la page (PHP, par exemple), à ​​la fois gallery.php et blog.php devront inclure certains common.php au début (ou à proximité). Cependant, les deux login.php et newpost.php peuvent inclure admin-common.php, qui tire lui-même dans 'common.php' et fait l'installation spécifique '/ admin /', comme pour vérifier que l'utilisateur est authentifié.

En général, si vous avez une hiérarchie d'URL, il finit par ressembler à des arborescences d'héritage d'objets. Sauf au lieu d'utiliser l'héritage au niveau de la langue, vous héritez de l'environnement de tout ce que vous incluez.

Je ne peux pas imaginer comment un contrôleur frontal augmente la testabilité, En fin de compte, les mêmes tests d'un agent utilisateur HTTP automatique sont requis, indépendamment de l'implémentation. Un inconvénient majeur des contrôleurs de page est qu'il rend votre application Web dépendante de son environnement d'hébergement.Cela oblige aussi vos développeurs à "voir" la même structure que les utilisateurs finaux, mais je considère cela comme une bonne chose, compte tenu du nombre de sites que je vois qui ont des URL absolument atroces.

Answer 2

Un avantage de l'utilisation d'un contrôleur frontal est sa testabilité. Si vous utilisez TDD, il est beaucoup plus facile de tester un contrôleur que de demander beaucoup de sites Web différents. Tom: Thea raison que je veux dire c'est plus testable parce que vous implémentez normalement les webhandlers en tant que classe plutôt que des pages de serveur. et puis vous pouvez faire beaucoup de tetst directement sur les classes.

Answer 3

Reformulation le Wikipedia article on Front Controller:

Dans une phrase - vous l'utilisez pour éviter les doubles emplois.

Un peu plus détaillée:

contrôleur avant «fournit un point d'entrée centralisé pour le traitement des demandes » Supposons que le contrôleur frontal de votre application Web est index.php.

Ce script, index.php, gérerait toutes les tâches communes à l'ensemble de l'application ou du framework, comme gestion de session, mise en cache, filtrage d'entrée. En fonction de l'entrée donnée, elle instancie d'autres objets et appelle des méthodes pour gérer la tâche particulière. L'alternative à un contrôleur frontal serait des scripts individuels tels que login.php et order.php qui incluraient chacun le code ou les objets communs à toutes les tâches. Cela nécessiterait une répétition du code d'inclusion dans chaque script mais pourrait également laisser plus de place aux besoins spécifiques d'un script.

Answer 4

Voici les raisons pour lesquelles je n'utiliserais jamais un contrôleur frontal.

• Nous avons un contrôleur avant parfaitement son appelé un navigateur Web.
• Chaque requête http est unique et distincte et doit être traitée comme telle.
• Il n'est pas possible de mettre à l'échelle une application à l'aide d'un contrôleur frontal.
• Si vous cassez une application Web en petits modules faiblement couplés, il est plus facile de tester l'unité/le module (vous ne testez pas l'architecture ni le contrôleur par exemple).
• Les performances sont meilleures si vous ne traitez qu'une seule requête.

Le modèle de contrôleur frontal ne convient tout simplement pas à mon humble avis. Créez des applications de la même manière qu'UNIX, divisez un problème plus important en petites unités qui effectuent une tâche et réalisez cette tâche très bien. La plupart des cadres poussent les développeurs à utiliser des contrôleurs frontaux et ils ont tout simplement tort.