Patrones de arquitectura clásicos

Audiocurso de Frameworks y Arquitecturas Frontend: Casos de Estudio

Contenido del curso

Introducción

1
¿Qué aprenderás en este curso?
01:35 min

Arquitectura de Frontend: Conceptos

Frameworks

Más allá del código

Tendencias en la arquitectura

Síguientes pasos

Cursos Empresas Blog Live Conf Eventos Precios

0:005:40

Patrones de arquitectura clásicos

Audiocurso de Frameworks y Arquitecturas Frontend: Casos de Estudio

Clase 3 de 15

Clase 3 / 15

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