2009-02-11 33 views
9

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 el patrón de controlador frontal?

¿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?

Respuesta

10

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

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

Si esto se lleva a cabo con los controladores de página (PHP, por ejemplo), tanto gallery.php y blog.php tendrá que incluir alguna common.php al principio (o cerca). Sin embargo, tanto login.php como 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, heredará el entorno de cualquier foo-common.php que incluya.

No puedo imaginarme 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 de las desventajas principales 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.

1

Una de las ventajas del uso de un controlador frontal es su capacidad de comprobación. Si usa TDD, es mucho más fácil probar un controlador que solicitar muchos sitios web diferentes.

Agregado después: Tom: 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.

6

reformular el Wikipedia article on Front Controller:

En una sentencia - lo utiliza para evitar la duplicación.

Un poco más detallada:

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

Este script, index.php, manejaría todas las tareas que son comunes para toda la aplicación o el framework, como manejo de sesión, almacenamiento en caché, 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.

9

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

  • Tenemos un controlador frontal perfectamente bueno que se conoce como un 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 sola solicitud de forma única.

El patrón de 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 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.

+1

"No es posible escalar una aplicación usando un controlador frontal." Esto parece evidente solo por la forma en que se debe asignar URI a las clases, pero ¿cuánto mejor va a funcionar el PHP sin formato una vez que se han considerado el acceso a datos y la E/S? –

+3

@FredWilson Mi punto sobre la escala es que si usa un controlador frontal significa que cada solicitud va a un único punto de entrada en todos los servidores. Si tiene puntos de entrada separados para cada parte de una aplicación, puede escalar cada pieza individualmente, p. Ej. una aplicación de correo: podría asignar más servidores a read-email.php que send-email.php ya que las personas generalmente leerán el correo electrónico con más frecuencia que el envío. Esto no se puede lograr con un controlador frontal, debería escalar todas las eventualidades juntas. – Pete

+0

¿Esta información sigue siendo relevante? Los marcos como Laravel, Zend Framework, Expressive y muchos otros parecen estar usando el patrón de controlador frontal exclusivamente y el enrutamiento directo al archivo se llama "obsoleto". (Https://stackoverflow.com/questions/48079853/what- are-these-routing-styles-called-in-a-web-application? noredirect = 1 # comment83133888_48079853) – Dennis

Cuestiones relacionadas