Coldfusion, ¿cuál es la ventaja del diseño del controlador frontal sobre el controlador de página?

Question

Soy de origen no informático y estoy luchando para entender los enfoques de diseño MVC y los marcos en general. "Obtuve" la reutilización del código, y la separación de la lógica de la pantalla, y "obtengo" encapsulación y desacoplamiento, pero no entiendo esto.

Por el momento simplemente pongo todo en la raíz, una subcarpeta separada para imágenes, cfcs e _includes, toda la interacción de la base de datos vía cfcs. Hago todo mi procesamiento en la parte superior de la página, luego una línea de comentarios y luego despliego/diseño de página debajo de eso.

La mayoría de los marcos que he visto parecen favorecer un controlador frontal, por lo que mi versión simplista de un controlador superior MVC sería una subcarpeta para cfcs, controladores y vistas y una gran declaración de cambio en index.cfm

<cfif not IsDefined("URL.event")> 
    <cflocation url="index.cfm?event=home" addtoken="No"> 
</cfif> 

<cfswitch expression="#url.event#"> 
    <cfcase value="home"> 
     <cfinclude template="controllers/home.cfm"/> 
     <cfinclude template="views/home.cfm"/> 
    </cfcase> 
    <cfcase value="about"> 
     <cfinclude template="controllers/about.cfm"/> 
     <cfinclude template="views/about.cfm"/> 
    </cfcase> 
</cfswitch> 

.. pero ¿qué ventaja real me da eso sobre el diseño de un controlador de página? A menos que sea solo el tipo de sitios que escribo, siempre me parece que la lógica del controlador es específica de una vista, no es como si un controlador pudiera adaptarse a varias vistas o varios controladores pudieran generar una sola vista, entonces ¿cuál sería el objetivo? separándolos?

La luz no se ha encendido todavía, ¿algún indicador?

Answer 1

Por el controlador "superior", creo que quiere decir "front" controller, un único punto de entrada para las solicitudes en una aplicación. Como escribió @bpanulla, la mayoría de los frameworks de ColdFusion usan este patrón de diseño. Esto se vuelve particularmente interesante con URL rewriting, donde es fácil tener search engine safe URLs interceptando la URL (por ejemplo, domain.ext/i/am/friendly.ext) y enrutando a algún archivo estándar como index.cfm mientras hace que la URL solicitada sea un parámetro (a menudo como un encabezado de solicitud). Esto también hace que el sitio se rediseñe donde las URL cambian más fácilmente porque se presta bien a alias o redirecciones.

Por lo que respecta a los controladores, por lo general, están estrechamente relacionados con un patrón de URL o URL en particular. Es posible combinarlo de forma más flexible con los controladores, pero en la práctica descubro que es una propiedad emergente después de varias refactorizaciones. Lo que debe subyacer al controlador es una o más llamadas a un service layer que habla con la base de datos, ejecuta un proceso comercial, crea entidades con estado, etc. Luego el controlador recibe las salidas de la capa de servicio y las coloca en cualquier mecanismo (por ejemplo, event objeto) se usa para pasar datos a la (s) vista (s).

Es la capa de servicio que debe ser reutilizable, no los controladores. Los controladores son simplemente una extensión del marco en el que funciona una aplicación.La idea es que usted deba poder cambiar los marcos con muy poco impacto en las vistas y la capa de servicio. La pieza que debe tocarse son los controladores.

Por lo tanto, un objeto de servicio dado en una capa de servicio debería ser capaz de dar servicio a varios controladores. Por ejemplo, considere mostrar la información de un usuario conectado como widget en un sitio. Puede haber diferentes páginas servidas por diferentes controladores, pero cada una llamaría al mismo objeto de servicio para obtener datos de usuario registrados que presumiblemente podrían asignarse a la misma vista que representa el widget.

Actualizar: Front Controller Ventajas

• Seguridad: autenticación centralizada y autorización.
• i18n & l10n: inyectar el paquete de idioma a la derecha en la solicitud global
• Proceso orquestación: pensar proceso de pago de múltiples fases para un carrito de la compra en el que no desea que los botones de avance y retroceso para trabajar - encaminando todo a través del controlador frontal que es capaz de cumplir lo que el paso (es decir, el estado)
• & registro de seguimiento de: añadir fácilmente Google Analytics o la otra petición de rastreo a un sitio al hacer la adición en un solo lugar
• Manejo de errores: Comportamiento centralizado

Ahora muchos de estos elementos también se puede hacer uso de <cferror> y Appplication.cfc, pero me resulta más fácil tener un punto centralizado.

Enlaces útiles

• http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
• http://msdn.microsoft.com/en-us/library/ff648617.aspx

Answer 2

Realmente implementó el quid de Fusebox (http://www.fusebox.org/) con lo que escribió. No hay nada de malo en eso, y la mayoría de la comunidad de ColdFusion usó algo similar a eso durante muchos años: Fusebox fue el marco CF más utilizado (en mi experiencia) hasta hace unos años cuando ModelGlue, Mach-II y el otro segundo generación de marcos CF se produjo.

Una cosa que puedo señalar es que su enfoque para los controladores (como archivos .cfm) en realidad no impone la encapsulación en la moda OOD típica, con argumentos específicos dirigidos a una llamada a un método de objeto. A menos que sea extremadamente diligente, con el tiempo sus controladores .cfm pueden terminar acumulando una gran cantidad de parámetros no documentados que alteran el comportamiento para resolver un problema u otro.

Con los diversos marcos también obtienes buenas características como aplicación, sesión y código específico de solicitud (onApplicationStart, onRequestEnd, etc.). Pero siempre puedes obtenerlos a través de un simple Application.cfc.