Esta división ha sido aprobado por expertos para asegurar la veracidad de nuestro contenido.
Solución:
Srikanth tiene una buena respuesta. Sin embargo, me gustaría dar más detalles sobre la alternativa. Supongamos 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 tendrá que incluir algunos common.php al principio (o cerca). Sin embargo, ambos login.php y newpost.php puede incluir admin-common.phpque a su vez extrae ‘common.php’ y hace 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 los á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 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 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 lo considero 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 llamado navegador web.
- Cada solicitud http es único y separado y debe ser tratado como tal.
- No es posible escalar una aplicación utilizando un controlador frontal.
- Si divide una aplicación web en pequeños módulos que están poco 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 sola 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 más grande en pequeñas unidades 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.
Reformulando el artículo de Wikipedia sobre Front Controller:
En una frase — lo 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 de 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 el marco de trabajo, como manejo de sesiones, almacenamiento en caché, filtrado de entrada. Dependiendo de la entrada dada, 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 secuencias de comandos individuales como login.php y order.php, cada uno de los cuales incluiría 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.