Modelo vista controlador: cómo separar responsabilidades

Curso Profesional de Arquitectura de Software

Contenido del curso

Introducción al curso

1
Curso Profesional de Arquitectura de Software
02:36 min

Atributos de calidad

Patrones de arquitectura

Diseño de una arquitectura

Modelado y documentación de arquitectura

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:005:37

Modelo vista controlador: cómo separar responsabilidades

Curso Profesional de Arquitectura de Software

Clase 14 de 43

Clase 14 / 43

Recursos

El modelo vista controlador es un patrón clave para organizar aplicaciones con claridad y escalabilidad. Al separar responsabilidades —lo que el usuario hace, cómo se representa el dominio y cómo se muestra en pantalla— permite que cada parte evolucione sin romper a las demás. Aquí entenderás su espíritu, sus variaciones y un ejemplo práctico centrado en la web.

¿Qué es modelo vista controlador y por qué separa responsabilidades?

El patrón divide el sistema en tres partes: la vista, el modelo y el controlador. La vista define cómo se ve la interfaz. El modelo describe qué puede hacer el sistema y representa el estado del dominio. El controlador gestiona las acciones del usuario y coordina la respuesta.

Separación de responsabilidades. La vista cambia sin tocar el modelo, y las acciones de usuario pueden reutilizar el mismo modelo y la misma vista.
Independencia de presentación y dominio. El modelo no debe conocer a las vistas ni cómo se muestran los datos. Así, el modelo evoluciona sin depender del diseño visual.
Comunicación focalizada. La relación más importante es entre vista y modelo, manteniendo bajo acoplamiento con el controlador cuando sea posible.
Flexibilidad sin exagerar la granularidad. No exige “un objeto por cada modelo” ni “una vista por cada tipo de aplicación”. Importa el rol, no la forma rígida.

¿Cómo se conectan vista, modelo y controlador en la práctica?

Lo esencial es definir cómo se comunican estos componentes. Hay implementaciones donde el controlador conoce a la vista y al modelo, y otras donde existen conectores alternativos. Cambian los enlaces, pero se mantiene la idea central: separar acciones del usuario, estado del sistema y presentación.

¿Qué ocurre en un ejemplo de carrito de compras y ruteo?

Imagina a una persona que desea ver su carrito de compras en un sitio web. La solicitud viaja a través de un ruteo que convierte una URL en un pedido a objetos hasta llegar a un controller.

El controller gestiona la acción: decide qué hacer para responder “ver el carrito”.
Coordina con el modelo: interactúa con el modelo que representa el carrito.
El modelo puede acceder a datos: ya sea mediante un ORM o ejecutando SQL queries.
El patrón no dicta persistencia: no define cómo conectarse a la base de datos, solo que exista un modelo que represente el estado del sistema.
La respuesta se renderiza con una vista: el controller puede elegir la vista adecuada.
Existen variaciones: el controller puede no conocer la vista; el ruteo puede vincularlos sin acoplarlos; incluso la vista puede observar al modelo y actualizarse sin controller en el medio.

¿Qué no define modelo vista controlador sobre persistencia?

El patrón no se preocupa por cómo el modelo se hace persistente ni por la tecnología de acceso a datos. Puede usar un ORM, consultas directas o no persistir. Lo crucial es que el modelo esté separado de la vista y del controlador.

¿Qué alternativas comparten el mismo espíritu de separación?

Existen patrones que comparten la misma idea de separar acciones del usuario, estado del sistema y presentación, variando en cómo conectan sus partes.

Model view, view model en C# y ASP .NET. Propone un modelo de vista que media entre la vista y el modelo, manteniendo responsabilidades separadas.
Modelo vista presentador. Cambia el rol de acción del usuario por un coordinador de vistas, pero sigue separado de vista y modelo.
Arquitectura flux. Define un flujo de datos de una sola vía, separando acciones de usuario (acciones), el modelo como store y las vistas como componentes de React.

¿Te gustaría compartir cómo aplicas estas separaciones en tus proyectos o qué variación te funcionó mejor?

Miguel Angel Reyes Moreno

Hace 2 años

Ejemplo de el directorio de archivos del e-commerce para este MVC:

/ecommerce-app

│

├── /controllers

│ ├── AuthController.js # Maneja el login, registro y autenticación de usuarios

│ ├── ProductController.js # Gestiona las operaciones con los productos (listar, ver detalles, etc.)

│ ├── CartController.js # Controla las acciones del carrito de compras

│ └── OrderController.js # Gestiona los pedidos y transacciones

│

├── /models

│ ├── User.js # Define el esquema del usuario y sus operaciones

│ ├── Product.js # Define el esquema del producto y sus operaciones

│ ├── Cart.js # Esquema del carrito de compras

│ └── Order.js # Esquema para el manejo de pedidos

│

├── /views

│ ├── /auth

│ │ ├── login.ejs # Vista para el formulario de inicio de sesión

│ │ └── register.ejs # Vista para el formulario de registro

│ ├── /products

│ │ ├── index.ejs # Vista que lista los productos

│ │ ├── show.ejs # Vista que muestra los detalles de un producto

│ └── /cart

│ ├── index.ejs # Vista para mostrar los productos en el carrito

│ └── checkout.ejs # Vista para el proceso de pago

│

├── /public

│ ├── /css

│ │ └── styles.css # Archivos CSS

│ ├── /images

│ │ └── logo.png # Imágenes del sitio

│ └── /js

│ └── scripts.js # Archivos JavaScript del frontend

│

├── /routes

│ ├── authRoutes.js # Define las rutas para autenticación (login, registro)

│ ├── productRoutes.js # Define las rutas para los productos

│ ├── cartRoutes.js # Define las rutas del carrito

│ └── orderRoutes.js # Define las rutas para gestionar pedidos

│

├── /config

│ ├── db.js # Configuración de la base de datos

│ └── config.js # Configuraciones generales (puerto, claves, etc.)

│

├── /middlewares

│ ├── authMiddleware.js # Middleware para proteger rutas privadas

│ └── errorHandler.js # Middleware para manejar errores

│

├── /services

│ ├── PaymentService.js # Servicio para gestionar pagos

│ └── EmailService.js # Servicio para enviar emails de confirmación

│

├── app.js # Archivo principal que arranca la aplicación

├── package.json # Dependencias del proyecto

└── README.md # Documentación del proyecto

Comentarios (35)35 comentarios

Francisco Serrato Jiménez

Hace 5 años

Carlos Pimentel

Hace 4 años

Antonio Obregón

Carlos Eduardo Diaz Polanco

Hace 8 años

Jose Neptali Iglesias Albuja

Hace 7 años

Eddy Arellanes

Hace 9 años

Stalin Alvarado

Diego Ramirez

Miguel Peláez

Mauricio Costanzo

Christian Gómez

Hace 6 años

Edinson Padrón

Misael Hernández Sánchez

Carla Salvatierra

José Iván Sandoya

JUAN PABLO MAYORGA MENDIETA

William Schnaider Torres Bermon

Antonio Rafael González Ferrer

Juan Carlos Ortiz Romero

Mijael Rodrigo Callejas Flores

Andrea Lascano

Hace 5 meses

Abril Darynka Tapia Sosa

Erik Elyager

Jose Carlos Heredia Rodriguez

José Antonio De La Paz Fonseca

Brayan Stiven Castaño Zuluaga

Introducción al curso

Curso Profesional de Arquitectura de Software

Atributos de calidad

Qué son los atributos de calidad en software

Cómo medir idoneidad funcional en software

Qué es eficiencia de ejecución en software

Cómo medir interoperabilidad y coexistencia

Qué es la usabilidad y sus 6 dimensiones

Cómo medir confiabilidad en software

Los 5 pilares de seguridad en software

Cómo garantizar mantenibilidad con tests

Adaptabilidad vs capacidad de instalación vs reemplazo

Tensiones entre atributos de calidad de software

Atributos de calidad según fase de empresa

Patrones de arquitectura

Qué es un patrón de arquitectura

Modelo vista controlador: cómo separar responsabilidades

Arquitectura en capas: controller, servicio y repositorio

Event sourcing vs bases relacionales

Qué es la arquitectura microkernel

Arquitectura Comparte Nada con Map Reduce

Patrón de microservicios: cuándo y cómo

Qué es CQRS y cómo separa lectura de escritura

Arquitectura hexagonal: puertos y adaptadores

Qué son los contextos delimitados en DDD

Cómo combinar patrones de arquitectura

Evolución de patrones desde monolito a microservicios

Diseño de una arquitectura

Cómo traducir requerimientos en decisiones arquitectónicas

Conectores en arquitectura: tipos y cuándo usarlos

Llamadas asíncronas vs síncronas vs cliente-servidor

Conector enrutador vs difusión: Twitter

Conectores cola, repositorio y pub/sub

Framework de diseño orientado a atributos

Cómo detectar fallas y reparar sistemas

Cómo recuperar y prevenir fallas en sistemas

Tácticas para confinar modificaciones

Cómo prevenir efectos dominó en software

Tácticas para controlar eficiencia de ejecución

Cómo detectar, resistir y recuperarse de ataques

Cómo probar que el software funciona correctamente

Cómo controlar la usabilidad con tácticas

Cómo validar arquitectura con ATAM y métricas

Evolución de arquitectura: startup a gran escala

Modelado y documentación de arquitectura

Cómo documentar arquitectura que no se erosione

Cómo sincronizar arquitectura y código fuente

Cómo aplicar atributos de calidad en proyectos

Modelo vista controlador: cómo separar responsabilidades