Controlador frontal frente a patrón de fachada

Question

Bien, he hecho un poco de búsqueda en línea y encontré el hilo this, pero todavía no lo aclaro por completo.

¿Cuál es exactamente la diferencia entre un patrón de controlador frontal y un patrón de fachada?

Según tengo entendido hasta ahora: Un patrón de fachada no contiene ninguna lógica comercial, sino que simplemente centraliza el acceso a múltiples objetos.

Un controlador frontal hace lo mismo, pero puede contener lógica comercial para facilitar la lógica de decisión de lo que se llama en función de los datos de entrada y similares.

Para dar sentido a esto, ¿el siguiente fragmento simplificado de pseudo código significa que drawLine es una Façade para simplificar la conversión de coordenadas a puntos y luego implementar el método de dibujo que realmente hace el trabajo?

private void drawLine(Int32 StartX, Int32 StartY, Int32 EndX, Int32 EndY) 
    { 
     Point Start = new Point(StartX, StartY); 
     Point End = new Point(EndX, EndY); 

     Draw(Start, End); 
    } 

Puede una fachada poner en capas inferiores de su aplicación o es en realidad sólo para centralizar el acceso a muchos de los componentes de la misma capa?

Según tengo entendido, el controlador frontal coordina el proceso de llamada a la función completa.

Ejemplo: Un controlador frontal examinará los datos y luego decidirá qué acción tomar. Luego compilaría los datos para cada llamada subsiguiente a las clases de nivel inferiores, hasta que llegue a una respuesta adecuada que pueda proporcionarse al sistema de llamadas.

Creo que mi comprensión del patrón Fachada es incorrecta o demasiado simplista. Por favor corrígeme si estoy equivocado.

Si mi comprensión de esto es correcta, ¿no tendría más sentido cambiar la fachada de la aplicación a un controlador frontal en el Microsoft Application Architecture Guide 2.0? Estoy buscando específicamente la arquitectura de servicio en el capítulo 18. (Tengo la versión Beta 2)

Actualización: Gracias por la excelente respuesta Rune. ¿Por qué dices que no es correcto cambiar la fachada a un controlador frontal? Soy un gran fan del Front-controller porque mantiene un poco más de control a todas las cosas de nivel inferior. Entonces, aunque puede no tener MÁS sentido, ¿sería completamente incorrecto hacer eso? ¿Si es así por qué?

Answer 1

El patrón del controlador frontal define un único componente que es responsable del procesamiento de las solicitudes de aplicaciones. A menudo se utiliza como un "cuello de botella" para (por ejemplo) solicitudes de canal a través de consolidar el comportamiento estándar que debe realizarse cada vez.

Ver estos enlaces para corta a las explicaciones puntuales:

• http://java.sun.com/blueprints/patterns/FrontController.html
• http://www.oracle.com/technetwork/java/frontcontroller-135648.html
• http://martinfowler.com/eaaCatalog/frontController.html

Una fachada es por el contrario más bien se usa para envolver otros métodos/servicios para proporcionar una interfaz unificada, ocultar la complejidad o reducir la dependencia de los sistemas externos (ejemplificado en la capa anticorrupción de DDD: http://www.goeleven.com/blog/entryDetail.aspx?entry=168), etc.

Una fachada es una envoltura delgada que no debe contener ninguna lógica, excepto la lógica utilizada para traducir entre los dos sistemas. El controlador frontal no tiene tales requisitos.

Véase, por ejemplo: http://en.wikipedia.org/wiki/Facade_pattern

Y para responder a sus preguntas relativas a AppArchGuide: No, eso no es correcto.

Answer 2

El patrón de controlador frontal es architectural pattern (impone una estructura arquitectónica en su aplicación).

El patrón de Fachada, por el contrario, es design pattern (se usa para estructurar una funcionalidad específica de su aplicación [un módulo], y no fuerza una estructura sobre toda su aplicación).