Simplificando controladores con Action-Domain-Responder (ADR)

Esta charla fue dada en el VLCTechFest'18. En ella veremos un poco de historia de la arquitectura MVC y por qué no es adecuada para entornos backend. Por otra parte veremos ejemplos del mundo real de controladores de aplicaciones web, para finalmente introducir ADR y ver como puede simplificar nuestra arquitectura y nuestro código en general.

Transcript

1. SIMPLIFICANDO CONTROLADORES: Una introducción a Action-Domain- Responder Miguel Ángel Sánchez Chordi @slaimer Valencia, 2 de junio de 2018
2. UN POCO SOBRE MÍ ! PHP Developer desde 2005. ! Miembro de PHP Valencia (anteriormente SymfonyVLC) desde 2013. ! Senior Backend Developer en Wossom. Anteriormente en Beroomers.com y Origo.by ! Tengo un blog sobre Clean Code! ◦ https://medium.com/all-you-need-is-clean-code ! Podcaster en “Leyendo Ciencia Ficción”!

3. UN POCO SOBRE MÍ Anteriormente me habrás visto en otras charlas en PHP Valencia como: ! Servicios Web REST (Breve introducción a REST) ◦ http://www.slideshare.net/slaimer/introduccin-a-rest-symfonyvlc ◦ https://www.youtube.com/watch?v=dWLuTVSMMfs 
 ! ¿Qué es OAuth y cómo se implementa? ◦ http://www.slideshare.net/slaimer/qu-es-eso-de-oauth ◦ https://www.youtube.com/watch?v=KONIDG1wp4g 

4. CONTROLADORES
5. CONTROLADORES El cajón de sastre de todo proyecto web
6. Patrón MVC - Introducción ! Los controladores son una de las 3 patas del patrón MVC ! MVC fue propuesto en 1979 ! Tuvo un gran auge en los 90 y a principios de 2000 ! Está pensado para su uso en aplicaciones de interfaz gráfica, donde cada componente (botón, input, menú…) tiene asociada su triada MVC.
7. Patrón MVC - Introducción ! Los controladores son una de las 3 patas del patrón MVC ! MVC fue propuesto en 1979 ! Tuvo un gran auge en los 90 y a principios de 2000 ! Está pensado para su uso en aplicaciones de interfaz gráfica, donde cada componente (botón, input, menú…) tiene asociada su triada MVC.
8. Patrón MVC - Componentes ! El Modelo es el actor principal, el que aglutina la lógica y actualiza el estado. ! La Vista es la parte visual de la aplicación, la representación final de los datos y de las acciones del usuario. ! La misión del Controlador es ser un canal de comunicación entre la vista y el modelo.
9. Patrón MVC - Componentes
10. Patrón MVC - Componentes
11. Patrón MVC - Componentes
12. Patrón MVC - Componentes
13. MVC en detalle ! En realidad, no es considerado un patrón arquitectónico, sino un patrón de interfaz de usuario. ! Si revisamos la literatura disponible en el momento de su concepción, siempre se hacen referencias a interacciones de usuario, elementos en pantalla, dispositivos de entrada… ! No se plantea como un patrón global para gobernar toda la aplicación, cada elemento en pantalla tiene su triada MVC ! Mediante un sistema de mensajería event/subscriber todos los elementos se mantienen comunicados.
14. MVC en aplicaciones web server-side ! Una aplicación web server-side (monolítica) no sigue este flujo, ya que se basa en peticiones HTTP. ! A cada petición que se hace se destruye y crea la interfaz gráfica ! No mantienen una interfaz “viva”.
15. SUN Microsystems y MODEL 2 ! La primera referencia a MVC y server-side viene de mano de SUN Microsystems, que se apropió del nombre de sus componentes para su patrón MODEL 2. ! SUN reinterpretó a su manera cada una de las partes de MVC, y gracias a el auge de Apache Struts, en el mundillo del desarrollo backend se asimilaron los componentes MVC tal cual los había planteado MODEL 2
16. SUN Microsystems y Model 2 En 1999 se podía leer en JavaWorld un artículo introductorio de MODEL 2 la siguiente recomendación: Properly applied, the Model 2 architecture should result in the concentration of all of the processing logic in the hands of the controller servlet, with the JSP pages responsible only for the view or presentation. Esta recomendación cuajó bastante entre los desarrolladores, quedando así para siempre confundido el concepto y el propósito de controlador MVC.
18. ¿QUÉ ASPECTO TIENE UN CONTROLADOR A DÍA DE HOY?
19. ¿QUÉ ASPECTO TIENE UN CONTROLADOR A DÍA DE HOY? Ejemplos de la Vida Real™
21. Control de “Daños” ! 618 líneas de código ! 30 imports ! 16 métodos ◦ 12 públicos ◦ 4 private/protected ! 106 líneas de comentarios
22. Control de “Daños” ! 618 líneas de código ! 30 imports ! 16 métodos ◦ 12 públicos ◦ 4 private/protected ! 106 líneas de comentarios
23. Cuando intentas explicar cómo está organizado el proyecto
25. ...cuando acabas de explicarlo...
27. ...cuando el P.O asigna una tarea a alguien nuevo...
29. ...cuando alguien se cansa y abandona el proyecto.
31. Problemas conocidos ! Contienen lógica de dominio.
32. Problemas conocidos ! Contienen lógica de dominio. ! Difícilmente testeables, y si contienen lógica de dominio, la situación se agrava (alta probabilidad de código duplicado).
33. Problemas conocidos ! Contienen lógica de dominio. ! Difícilmente testeables, y si contienen lógica de dominio, la situación se agrava (alta probabilidad de código duplicado). ! Archivos enormes
34. Problemas conocidos ! Contienen lógica de dominio. ! Difícilmente testeables, y si contienen lógica de dominio, la situación se agrava (alta probabilidad de código duplicado). ! Archivos enormes ! Configuraciones incrustadas (anotaciones)
35. Problemas conocidos ! Contienen lógica de dominio. ! Difícilmente testeables, y si contienen lógica de dominio, la situación se agrava (alta probabilidad de código duplicado). ! Archivos enormes ! Configuraciones incrustadas (anotaciones) ! Difícil mantenimiento y peor crecimiento del proyecto
36. Problemas conocidos ! Contienen lógica de dominio. ! Difícilmente testeables, y si contienen lógica de dominio, la situación se agrava (alta probabilidad de código duplicado). ! Archivos enormes ! Configuraciones incrustadas (anotaciones) ! Difícil mantenimiento y peor crecimiento del proyecto ! Curva de aprendizaje para nuevas incorporaciones
37. Problemas conocidos ! Contienen lógica de dominio. ! Difícilmente testeables, y si contienen lógica de dominio, la situación se agrava (alta probabilidad de código duplicado). ! Archivos enormes ! Configuraciones incrustadas (anotaciones) ! Difícil mantenimiento y peor crecimiento del proyecto ! Curva de aprendizaje para nuevas incorporaciones ! No es SOLID
38. ACTION-DOMAIN-RESPONDER
39. ACTION-DOMAIN-RESPONDER La alternativa
40. Breve Introducción Propuesto por Paul M. Jones, ADR nace como una alternativa server-side “real” a MVC, siendo un patrón pensado para aplicaciones de red en un entorno Request/ Response. Esto es una ventaja considerable, teniendo en cuenta que la mayoría de frameworks web actuales implementan este flujo Request/Response
41. Breve Introducción No es complejo pasar de comprender MVC o MODEL 2 a comprender ADR, las bases son las misma, pero con pequeñas adaptaciones que hacen que sea más cómodo de mantener y de modelar nuestro sistema. Veamos una comparación de los distintos componentes a continuación.
42. Model VS Domain
43. Model VS Domain ! Poca diferencia respecto al Modelo original
44. Model VS Domain ! Poca diferencia respecto al Modelo original ! Responder y Domain no interactúan nunca, a pesar de ello, el Responder puede usar elementos de dominio como entidades o colecciones con fines de presentación.
45. Model VS Domain ! Poca diferencia respecto al Modelo original ! Responder y Domain no interactúan nunca, a pesar de ello, el Responder puede usar elementos de dominio como entidades o colecciones con fines de presentación. ! El Domain no está concebido como una única clase que gestione la lógica.
46. Model VS Domain ! Poca diferencia respecto al Modelo original ! Responder y Domain no interactúan nunca, a pesar de ello, el Responder puede usar elementos de dominio como entidades o colecciones con fines de presentación. ! El Domain no está concebido como una única clase que gestione la lógica. ! La elección de nombre no es casual. Se pretende “forzar” al programador a pensar en patrones propios de DDD como Application Service o Use Case para modelar el dominio de la aplicación.
47. Model VS Domain ! Poca diferencia respecto al Modelo original ! Responder y Domain no interactúan nunca, a pesar de ello, el Responder puede usar elementos de dominio como entidades o colecciones con fines de presentación. ! El Domain no está concebido como una única clase que gestione la lógica. ! La elección de nombre no es casual. Se pretende “forzar” al programador a pensar en patrones propios de DDD como Application Service o Use Case para modelar el dominio de la aplicación. ! Cualquier acción que el sistema pueda ejecutar, pertenece a la capa de dominio
48. View VS Responder
49. View VS Responder ! En MVC clásico, el controlador es el encargado de generar el cuerpo de la respuesta (bien serializando el contenido o renderizando una plantilla) y de inyectarlo en la respuesta, manejando status code, cabeceras, cookies… etc.
50. View VS Responder ! En MVC clásico, el controlador es el encargado de generar el cuerpo de la respuesta (bien serializando el contenido o renderizando una plantilla) y de inyectarlo en la respuesta, manejando status code, cabeceras, cookies… etc. ! Para separar por completo lógica de presentación, ADR introduce el Responder, el componente encargado de gestionar toda la creación de la respuesta, quitándole dicha responsabilidad al controlador.
51. View VS Responder ! En MVC clásico, el controlador es el encargado de generar el cuerpo de la respuesta (bien serializando el contenido o renderizando una plantilla) y de inyectarlo en la respuesta, manejando status code, cabeceras, cookies… etc. ! Para separar por completo lógica de presentación, ADR introduce el Responder, el componente encargado de gestionar toda la creación de la respuesta, quitándole dicha responsabilidad al controlador. ! Un mismo responder debe de poder ser utilizado por más de un Action, no consiste necesariamente en que haya una Responder por cada Action, sino en que sea el Responder quien manipule la respuesta.
52. Controller VS Action
53. Controller VS Action ! Los controladores “MODEL 2/MVC” suelen tener varios métodos públicos que corresponden a varias rutas/acciones.
54. Controller VS Action ! Los controladores “MODEL 2/MVC” suelen tener varios métodos públicos que corresponden a varias rutas/acciones. ! Esto hace que la clase tenga dependencias muy variadas, que el constructor reciba demasiadas dependencias o que el controlador requiera tener directamente tener el container de dependencias.
55. Controller VS Action ! Los controladores “MODEL 2/MVC” suelen tener varios métodos públicos que corresponden a varias rutas/acciones. ! Esto hace que la clase tenga dependencias muy variadas, que el constructor reciba demasiadas dependencias o que el controlador requiera tener directamente tener el container de dependencias. ! En ocasiones un mismo controlador hay acciones que devuelven contenido en HTML y otras en XML/JSON o cualquier otro tipo de serializado. Provocando que el controlador tenga aún más dependencias.
56. Controller VS Action ! Los actions de ADR en cambio, corresponden cada uno a una única acción.
57. Controller VS Action ! Los actions de ADR en cambio, corresponden cada uno a una única acción. ! Esto ya sucede en microframeworks como Slim, Silex, Hanami, Flask… donde cada ruta se corresponde directamente con una closure o una clase individual.
58. Controller VS Action ! Los actions de ADR en cambio, corresponden cada uno a una única acción. ! Esto ya sucede en microframeworks como Slim, Silex, Hanami, Flask… donde cada ruta se corresponde directamente con una closure o una clase individual. ! Un action interactúa con el dominio de la misma forma que un controlador interactúa con el modelo, pero no interactúa con la vista: envía la información al responder para que este sea el que haga su trabajo
59. Controller VS Action ! Los actions de ADR en cambio, corresponden cada uno a una única acción. ! Esto ya sucede en microframeworks como Slim, Silex, Hanami, Flask… donde cada ruta se corresponde directamente con una closure o una clase individual. ! Un action interactúa con el dominio de la misma forma que un controlador interactúa con el modelo, pero no interactúa con la vista: envía la información al responder para que este sea el que haga su trabajo ! Más allá de validar la request (método, cabeceras, parámetros, cookies o autenticación), el resto queda delegado a domain y responder.
60. Ventajas de su uso
61. Ventajas de ADR frente a MVC ! Fuerte separación de responsabilidades
62. Ventajas de ADR frente a MVC ! Fuerte separación de responsabilidades ! Clases muy pequeñas
63. Ventajas de ADR frente a MVC ! Fuerte separación de responsabilidades ! Clases muy pequeñas ! Fácilmente testeable
64. Ventajas de ADR frente a MVC ! Fuerte separación de responsabilidades ! Clases muy pequeñas ! Fácilmente testeable ! Favorece al uso de patrones de comportamiento para modelar el dominio
65. Ventajas de ADR frente a MVC ! Fuerte separación de responsabilidades ! Clases muy pequeñas ! Fácilmente testeable ! Favorece al uso de patrones de comportamiento para modelar el dominio ! Contribuye al naming de clases, simplificando la comprensión del proyecto
66. Ventajas de ADR frente a MVC ! Fuerte separación de responsabilidades ! Clases muy pequeñas ! Fácilmente testeable ! Favorece al uso de patrones de comportamiento para modelar el dominio ! Contribuye al naming de clases, simplificando la comprensión del proyecto
67. Ventajas de ADR frente a MVC ! Fuerte separación de responsabilidades ! Clases muy pequeñas ! Fácilmente testeable ! Favorece al uso de patrones de comportamiento para modelar el dominio ! Contribuye al naming de clases, simplificando la comprensión del proyecto ! El añadir nuevos casos de uso es casi mecánico
68. Ventajas de ADR frente a MVC ! Fuerte separación de responsabilidades ! Clases muy pequeñas ! Fácilmente testeable ! Favorece al uso de patrones de comportamiento para modelar el dominio ! Contribuye al naming de clases, simplificando la comprensión del proyecto ! El añadir nuevos casos de uso es casi mecánico ! Anima a seguir principios SOLID y Clean Code
69. Show me the code! https://github.com/mangelsnc/adr-blog
70. Preguntas???
71. GRACIAS POR VENIR!