Patrones de arquitectura clásicos

Clase 3 de 15 • Audiocurso de Frameworks y Arquitecturas Frontend: Casos de Estudio

Giuliano De Leonardis

student•

Patrones del lado del frontend

Patrón MVC (Model–view–controller)

Es uno de los patrones de arquitectura más conocidos y más utilizados.
Fue introducido en 1979.
Hoy en día ya no es tan usado; sigue siendo un patrón muy util para entender la arquitectura de software.
Se basa en tres capas:
- Modelo: se encarga de la lógica de negocio, es decir, de la lógica que procesa los datos de nuestra aplicación.
- Vista: se encarga de mostrar os datos del modelo, es decir, la interfaz del usuario.
- Controlador: gestiona las interacciones del usuario con la vista y comunicarlos al modelo.

Ejemplo en la vida real: sería un restaurante...
- Modelo: sería la cocina
- Vista: carta de platos
- Controlador: camarero o mesonero; se encarga de gestionar las peticiones de los clientes a la cocina.
Separa la lógica de negocio (procesamiento de datos) de la lógica de presentación (mostrar los datos).

MVVM (Model–view–viewmodel)

Es una evolución del MVC
Diferencia: en lugar de contar con un controlador cuenta con un view model, mientras el "controlador" sincroniza la vista con el modelo manualmente, lo que hacemos con el view-model es que se encargue de hacerlo automaticamente.
Problema histórico: al aplicarse a la web falta la gestión del estado.

FLUX Patrón que ha revolucionado la arquitectura en el frontend. Fue creado por Facebook (Meta).

Se basa en un único flujo de datos. Todos los datos viajan en un único sentido
Vista: sería la misma que tenemos en el patrón MVC
Cuando el usuario interactua con la vista, esta le envia una acción al dispatcher
Dispatcher: es el encargado de enviar la acción a todas las stores
Las stores son las encargadas de procesar la acción y actualizar el estado de la aplicación. Cada vez que eso ocurre, el estado de la aplicación cambia y los stores notifican a la vista para que refleje estos cambios.
Una evolución de este patrón (Flux) es el que aportaba Redux donde se añadia un nuevo componente: el reducer.
Reducer: es el encargado de procesar la acción y actualizar el estado de la aplicación, y es que, en lugar de que sean las stores que se encarguen de esto, lo que hacemos es que el reducer se encargue de ello.

En general queremos que nuestra aplicación sea fácil de mantener y fácil de extender, y una de las formas de lograrlo es separando responsabilidades.
Hemos evolucionado a un patrón mucho más reactivo, donde la cascada de cambios se produce de forma automática.
Aplicar un patrón al 100% es complicado.
A veces no se sabe aplicar bien cada patrón.
Evita adoptar uno de estos patrones sin antes entender bien qué es lo que te aporta

Gustavo Pú

student•

Exelente aporte💚

Miguel Ángel Durán García

teacher•

👏👏👏👏👏

Jose Barboza

student•

¿en que caso se puede usar todavia el patron MVC?, por ejemplo cuando trabajas con laravel usa este patron para hacer una app fullstack.

Miguel Ángel Durán García

teacher•

Pues ya te has respondido. Todavía existen frameworks con siguen este patrón. Laravel es un ejemplo. También en .NET puede ser una buena idea muchas veces por la cantidad de documentación y porque el framework te guía.

Jose Barboza

student•

es mucho mas facil extender y mantener una aplicación que sigue un patron de arquitectura de software que una que no.

David Elias Gatica Morales

student•

Muy buena esta clase

Patrones de arquitectura clásicos

Introducción

¿Qué aprenderás en este curso?

Arquitectura de Frontend: Conceptos

¿Qué es la Arquitectura en el Frontend?

Patrones de arquitectura clásicos

Clean Architecture en el Frontend

Screaming Architecture

Frameworks

Tipos de renderizado: Server Side Rendering, Client Side Rendering y modos estáticos

Next.js, Nuxt.js, Astro, Remix...

Más allá del código

Monorepositorios vs. Multirepositorios

Flujos de trabajo en Git para trabajar en equipo

Objetivo: crear una plataforma web

Tendencias en la arquitectura

La mala fama de los monolitos

Microfrontends: ¿qué son y cuándo usarlos?

Backend for Frontend

Síguientes pasos

¿Cómo elegir mi arquitectura de frontend y framework?

¿Y ahora por dónde sigo?