La descripción básica de Modelo-Vista-Controlador es que es una arquitectura de tres capas epónimas, la cual fue inventada en SmallTalk y que se volvió obsoleta al ser reemplazada por el paradigma de componentes (controles) en formularios.
O al menos eso sería, si a los señores de Ruby on Rails no se les hubiera ocurrido que era una buena idea para organizar un marco de trabajo para aplicaciones web.
Primero que todo, un marco de trabajo para aplicaciones web tiene Internet en el medio. El código de la vista se ejecuta en el lado del cliente, pero la vista es construida en el lado del servidor. Así que en realidad tenemos que dividir la vista en dos (porque tiene Internet en la mitad): vista y presentador. El presentador es, por supuesto, la capa responsable de crear la vista.
Nota: Dependiendo el lado que tomen en la guerra, algo similar puede ocurrir en el otro extremo de la arquitectura. Utilizando un ORM para construir las sentencias y consultas que se ejecutan contra la base de datos.
Ahora, la vista recibe la entrada del usuario y la envía al controlador. Sin embargo, ya que la vista se dividió en dos, el presentador no recibe la entrada. Esto es, que desde el punto de vista del servidor, el presentador hace la salida, y el controlador recibe la entrada.
Ahora, idealmente tendremos diferentes controladores para diferentes partes de la aplicación. No es raro crear vistas y controladores en pareja. Porque en realidad, deberíamos reemplazar modelo-vista-controlador por componentes. En consecuencia, necesitamos una pieza de software que se dedica a elegir que controlador debe manejar la entrada. A esto le llamamos Enrutador.
Así tenemos Vista-Presentador-Enrutador-Controlador-Modelo
Ahora, hay otras preocupaciones (como se entiende en programación orientada a aspectos), por ejemplo:
- Control de acceso
- Gestión de caches
- Escribir logs
- Enviar correo electrónico
Etcétera...
Si ponemos todo este código en el controlador, el controlador tendría más de una responsabilidad. Esto hace en controlador difícil de mantener. Si movemos todo esto al modelo, hacemos el modelo difícil de mantener... y si pensamos en Modelo-Vista-Controlador, esas son las únicas opciones que tenemos.
Lo que debemos hacer es crear servicios para Control de acceso, Gestión de cache, y Logs, y darle al Enrutador la responsabilidad de integrarlos.
Por otro lado, en la mayoría de los casos sabemos que datos va a necesitar el controlador, así podemos leer de configuración o de base de datos y pasar los datos al controlador. Al hacer esto, el controlador ya no depende del modelo.
De hecho, podemos hacer que el Enrutador no lea de configuración y base de datos, sino que simplemente llame servicios, así la información puede venir de cualquier sistema externo (no solo base de datos).
Y en cuanto a escribir, el controlador puede llamar servicios para escribir. De esa forma, la información puede ir a cualquier sistema externo, no solo a base de datos.
Luego hay que llamar al presentador para crear la respuesta. El controlador debe dar los datos que hay que mostrar. Y tendremos que ajustarlos a la estructura que necesitamos para presentación.
Hablo aquí en voz pasiva porque hay varias soluciones:
- El Enrutador llama al controlador, el controlador prepara los datos para la vista, luego el controlador llama al al presentador pasando los datos.
- El Enrutador llama al controlador, el controlador prepara los datos para la vista y los devuelve al Enrutador, luego el Enrutador llama al presentador pasando los datos.
- El Enrutador llama al controlador, el controlador devuelve los datos de forma agnóstica al Enrutador, luego el Enrutador llama al presentador pasando los datos, el cual se encarga de prepararlos para la vista.
- Fusionamos el controlador y el presentador, lo seguimos llamando controlador, y el Enrutador lo llama.
- El Enrutador llama al controlador, el controlador devuelve los datos de forma agnóstica al Enrutador, el Enrutador llama al Mapeador, el cual prepara los datos para la vista y los devuelve al Enrutador, luego el Enrutador llama al presentador pasando los datos.
- El Enrutador llama al controlador, el controlador devuelve los datos de forma agnóstica al Enrutador, luego el Enrutador llama al presentador pasando los datos, el cual llama al Mapeador para preparar los datos para la vista.
Etcétera...
Lo cierto es que he descompuesto Modelo-Vista-Controlador, pero necesitamos pensar un poco más en como reconstruir la arquitectura.
Este articulo está basado en la presentación "Deconstructing the framework" por "Gary Bernhardt"
Comentarios
Publicar un comentario