patterns pattern learning es6 book design-patterns front-controller

design-patterns - learning - prototype pattern javascript



¿Cuáles son las ventajas y desventajas de usar el patrón de controlador frontal? (4)

Actualmente diseño todos mis sitios web con un archivo para cada página, luego incluyo elementos comunes como el encabezado, el pie de página, etc. Sin embargo, he notado que muchos frameworks y CMS usan el patrón Front Controller.

¿Cuáles son las ventajas y desventajas de usar un controlador frontal? ¿El patrón simplemente se usa en marcos y CMS porque no se sabe qué páginas existirán en el sistema final?


Reformulando el artículo de Wikipedia sobre el controlador frontal :

En una oración, la usas para evitar la duplicación .

Un poco más detallado:

El controlador frontal "proporciona un punto de entrada centralizado para el manejo de solicitudes". Supongamos que el controlador frontal para su aplicación web es index.php .

Esta secuencia de comandos, index.php, manejaría todas las tareas que son comunes a toda la aplicación o al marco, como el manejo de sesión, el almacenamiento en caché y el filtrado de entrada . Dependiendo de la entrada dada, entonces instanciaría más objetos y métodos de llamada para manejar la tarea en particular.

La alternativa a un controlador frontal serían los scripts individuales como login.php y order.php que incluirían el código u objetos que son comunes a todas las tareas. Esto necesitaría una repetición del código de inclusión en cada script, pero también podría dejar más espacio para las necesidades específicas de un script.


Srikanth tiene una buena respuesta. Me gustaría elaborar sobre la alternativa, sin embargo. Supongamos que tiene esta simple jerarquía de URL:

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

Si esto se implementa con Page Controllers (PHP, por ejemplo), tanto gallery.php como gallery.php necesitarán incluir algún common.php al principio (o cercano). Sin embargo, login.php y newpost.php pueden incluir admin-common.php , que a su vez extrae ''common.php'' y ''/ admin /'' - configuración específica, como verificar que el usuario esté autenticado.

En general, si tiene una jerarquía de URL, termina pareciéndose mucho a los árboles de herencia de objetos. Excepto que en lugar de usar herencia a nivel de lenguaje, estás heredando el entorno de cualquier foo-common.php que incluyas.

No puedo imaginarme cómo un controlador frontal aumenta la capacidad de prueba. Al final, se requieren exactamente las mismas pruebas de un agente de usuario HTTP automatizado, independientemente de la implementación.

Una de las principales desventajas de Page Controllers es que hace que su aplicación web dependa de su entorno de alojamiento. También obliga a los desarrolladores a "ver" la misma estructura que los usuarios finales, pero considero que es algo bueno, teniendo en cuenta la cantidad de sitios que veo que tienen URL absolutamente atroces.


Una ventaja de usar un controlador frontal es su capacidad de prueba. Si usa TDD, es mucho más fácil probar un controlador que solicitar muchos sitios web diferentes.

Agregado más adelante: Tom: Thea, la razón por la que quiero decir que es más comprobable es porque normalmente implementa los manejadores web como clase en lugar de páginas de servidor. y luego puedes hacer muchas cosas directamente en las clases.


Estas son las razones por las que nunca usaría un controlador frontal.

  • Tenemos un controlador frontal perfectamente bueno que se llama navegador web.
  • Cada solicitud http es única y separada y debe tratarse como tal.
  • No es posible escalar una aplicación usando un controlador frontal.
  • Si divide una aplicación web en pequeños módulos que están ligeramente acoplados, es más fácil probar la unidad / módulo (no está probando la arquitectura ni el controlador, por ejemplo).
  • El rendimiento es mejor si se ocupa de una única solicitud de forma única.

El patrón del controlador frontal simplemente no se ajusta en mi humilde opinión. Cree aplicaciones de la misma manera que UNIX, divida un problema más grande en unidades pequeñas que realizan una tarea y realice esa tarea realmente bien. La mayoría de los marcos están empujando a los desarrolladores a usar controladores frontales y simplemente están equivocados.