No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Aprende Ingl茅s, Programaci贸n, AI, Ciberseguridad y m谩s a precio especial.

Antes: $249

Currency
$209
Suscr铆bete

Termina en:

1 D铆as
23 Hrs
36 Min
6 Seg

Patrones de arquitectura cl谩sicos

3/15
Recursos

Aportes 2

Preguntas 1

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

Patrones del lado del frontend

Patr贸n MVC (Model鈥搗iew鈥揷ontroller)

  • 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鈥搗iew鈥搗iewmodel)

  • Es una evoluci贸n del MVC
  • Diferencia: en lugar de contar con un controlador cuenta con un view model, mientras el 鈥渃ontrolador鈥 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

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