Por lo general, contar con un modelo de datos que tengan diferentes estados por lo que vamos pasando es algo bastante normal. Pensar en conceptos como artículos de un blog por ejemplo, que primeramente se crean como borrador y luego, son derivados a editores, quienes los controlan, corrigen y toman decisión de publicar estos artículos o no, o pensar en concepto más complejos como podrían ser las decisiones de otorgar créditos a usuarios de una entidad financiera, nos llevan a pensar en entidades que manejan un “estado”.
El concepto de cambio de estados es en realidad bastante sencillo de entender, pero es muy común ver códigos de desarrolladores repletos de if, esparcidos por toda la aplicación para ir evaluando y cambiando estos objetos de un estado a otro.
Esto se complejiza más aún, cuando a demás de solo el cambio de estado, hay que controlar permisos de acuerdo a los roles de los usuarios para realizar ciertos cambios de estado o lo que comúnmente conocemos como acciones de los usuarios dentro de un concepto de proceso de negocio.
Para buscar una definición sencilla de entender, simplemente hay que pensar en un workflow o flujo de trabajo, como la definición de rutas posibles, acciones y cambios de estados para objetos que van avanzando en la lógica de ese negocio en particular.
En el ejemplo que venimos viendo, esto aplica para los comentarios de las conferencias que, como vimos en los capítulos anteriores, deben pasar por una verificación para filtrar comentarios de tipo spam.
Vamos a agregar un poco más de complejidad sobre esto para hablar sobre este componente de symfony, que viene a darnos una mano para evitar los famosos códigos de tipo spaguetti, esparcidos por toda la aplicación y que lo único que hacen es complicar más la lectura y el mantenimiento de nuestros sistemas. Desde ya hace varios años venimos comentando que la lógica del negocio debe estar separada de las vistas, cosa que para los desarrolladores php que venimos hace varios años trabajando con este lenguaje, recordarán que antes estaba todo en la misma página y que los modelos de tipo model-view-controller nos ayudan a solucionar. A este concepto, vamos a sumar una división más, separando de la lógica del negocio relacionada a validaciones y cálculos, todo lo relacionados a los flujos de trabajo y control de estado por los que pasa nuestro modelo.
Para esto, vamos a modificar lo que venimos haciendo con el verificador de spam, agregando al administrador del sitio como la persona, que luego de tener un primer filtro automático con el servicio de akismet, tendrá que tomar la decisión de publicar o no el comentario.
De esta forma, un comentario siempre iniciaría con el estado submitted o enviado, luego el verificador de spam de forma asíncrona, como lo vimos en el capítulo anterior, analiza el comentario para determinar si no es spam, si es potencialmente un spam o si lo reconoce efectivamente como spam y lo rechaza directamente.
En caso de no rechazarlo automáticamente, el usuario administrador del sitio deberá ser el que decida si el comentario es lo suficientemente bueno para publicarlo cambiado el estado a publicado o en caso contrario rechazarlo manualmente.
En este capitulo nos vamos a centrar en la primera parte, definiendo el workflow de trabajo y en el siguiente vamos a involucrar el administrador del sitio.
En el siguiente video, vamos a continuar con el procesamiento del workflow, enviando alertas por correo electrónico a los administradores del sitio, para tomar las decisiones sobre los comentarios y accionar los siguientes pasos sobre nuestro flujo de trabajo.
[sc name=»posts_symfony5_la_via_rapida» ]Descubre más desde Neurosimbiosis
Suscríbete y recibe las últimas entradas en tu correo electrónico.