Solución:
Srikanth tiene una buena respuesta. Sin embargo, me gustaría dar más detalles sobre la alternativa. Suponga que tiene esta jerarquía de URL simple:
/gallery /blog /admin/login /admin/newpost
Si esto se implementa con controladores de página (PHP, por ejemplo), ambos gallery.php y blog.php necesitará incluir algunos common.php al principio (o cerca). Sin embargo, ambos login.php y newpost.php puede incluir admin-common.php, que a su vez extrae ‘common.php’ y realiza una configuración específica de ‘/ admin /’, como verificar que el usuario esté autenticado.
En general, si tiene una jerarquía de URL, termina pareciéndose mucho a árboles de herencia de objetos. Excepto que en lugar de usar la herencia a nivel de idioma, está heredando el entorno de lo que sea foo-common.php usted incluye.
No puedo imaginar cómo un controlador frontal está aumentando 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 desventaja importante de los controladores de página es que hace que su aplicación web dependa de su entorno de alojamiento. También obliga a sus desarrolladores a “ver” la misma estructura que los usuarios finales, pero considero que es algo bueno, considerando la cantidad de sitios que veo que tienen URL absolutamente atroces.
Estas son las razones por las que nunca usaría un controlador frontal.
- Tenemos un controlador frontal perfectamente bueno, se llama navegador web.
- Cada solicitud http es única e independiente 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 débilmente 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 encaja en mi humilde opinión. Cree aplicaciones de la misma manera que UNIX, divida un problema mayor en unidades pequeñas que realicen una tarea y realice esa tarea realmente bien. La mayoría de los marcos están presionando a los desarrolladores para que usen controladores frontales y simplemente están equivocados.
Parafraseando el artículo de Wikipedia sobre Front Controller:
En una frase — lo usas para evitar duplicaciones.
Un poco más detallado:
El controlador frontal “proporciona un punto de entrada centralizado para manejar solicitudes”. Supongamos que el controlador frontal de su aplicación web es index.php.
Este script, index.php, manejaría todas las tareas que son comunes a toda la aplicación o al marco alrededor, como manejo de sesiones, almacenamiento en caché, filtrado de entrada. Dependiendo de la entrada dada, luego instanciaría más objetos y llamaría a métodos 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 cada uno 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 secuencia de comandos, pero también podría dejar más espacio para las necesidades específicas de una secuencia de comandos.