Arquitectura MVT en Frameworks Web: Model, View y Template

Resumen

La arquitectura del framework está diseñada para ser reutilizable y organizar todas tus tareas. Utiliza el modelo MVT (Model, View, Template).

¿Qué es el modelo en MVT (Model, View, Template)?

El modelo es la parte de los datos:

Guarda y procesa los datos.
Contiene la lógica del negocio, como una calculadora que suma 2 más 2.

¿Qué es la vista en MVT?

La vista actúa como un conector:

Accede y dirige los datos.
Controla el flujo de peticiones y respuestas.
Verifica permisos y realiza comprobaciones necesarias.

¿Qué es el template en MVT?

El template maneja la parte gráfica:

Usa HTML y CSS para mostrar los datos.
Por ejemplo, muestra una lista de zapatos almacenada en el modelo.

¿Cómo interactúan modelo, vista y template?

El flujo de datos es el siguiente:

El modelo pasa datos a la vista en un array.
La vista pasa esos datos al template en un contexto.
El template muestra los datos gráficos.

En sentido contrario:

Un usuario busca en el template.
La vista recibe la búsqueda y consulta al modelo.
El modelo devuelve los resultados a la vista.
La vista envía los datos al template para mostrarlos.

Nota: No debe haber conexión directa entre template y model. Siempre usa la vista para asegurar verificaciones y permisos.

Nahuel Seoane

student•

Que raro no pongan un resumen en la parte de Recursos, a mi me fue siempre útil leerlo. Por más que el profe explique muy bien la parte escrita aporta términos más exactos para entender el tema, al menos para mí.

Oscar Barajas Tavares

Team Platzi•

Juan, ya está disponible el resumen.

Nahuel Seoane

student•

@gndx muchas gracias

Jenny Aguilar

student•

No se si será lo mismo pero la estructura me evoca a la estructura MVC (Modelo Vista Controlador) solo que en este caso Vista viene a corresponderse con el Controlador, y el Template con la Vista del otro modelo. Si alguien tiene un comentario al respecto, se agradece.

Carlos Esteban León Pinilla

student•

Literal, según lo que investigue. Es solo una implementación que cambia los nombres, pero la lógica y el propósito es equivalente a MVC.

Menkar Felipe Cantor Molina

student•

Si eso fue algo que me genero mucha confusion debido a que en MVT la vista se comporta como un controlador.

Pablo Hurtado

student•

En primer párrafo tiene un error en la frase "... Utiliza el modelo MBT: Model, View y Template." en lugar de MBT debería ser MVT

Carlos Esteban León Pinilla

student•

Que bueno saber como es la arquitectura, pero no me queda claro que necesidad de crear otra si es literalmente lo mismo a la arquitectura MVC.

Según investigaciones que hago, es una implementación basada en MVC, pero no le veo la diferencia ya que son equivalentes, es decir:

Model (MVC) = Model (MTV)
View (MVC) ≈ Template (MTV)

Controller (MVC) ≈ View (MTV)

Buscando en algunas AIs, como GPT y Gemini, dicen que:

En esencia, MVC y MTV son muy similares y las diferencias son principalmente terminológicas y de enfoque sutil. Permítame reconocer y explicar este punto:

- Similitud funcional: Ambos patrones dividen la aplicación en tres componentes principales que manejan datos, lógica de negocio y presentación

- Diferencia más nominal que funcional: La distinción es más una cuestión de nomenclatura y énfasis que de diferencia estructural real.

- Adaptación contextual: MTV es esencialmente la interpretación de Django del patrón MVC, adaptado a su filosofía y estructura.

- Propósito similar: Ambos buscan separar responsabilidades y mejorar la organización del código.

Es correcto decir que las diferencias son mínimas y que, en la práctica, trabajar con MTV en Django no es fundamentalmente diferente de trabajar con MVC en otros frameworks.

Lo que me hace pensar que esta adaptación es solo para darle una distinción entre los otros frameworks como Ruby on Rails o Laravel. Ya saben, cosas del mundo Tech 😅

Ivek Martínez Herrera

student•

Si cambia como manejas la lógica, en ror es mvc y la lógica de tu aplicación viene en el controlador y Django es en los template osea que el código de PYTHON va estar en esa parte, cuando trabajes vas a ver la diferencia en la configuración y como mandar los request, yo poco he trabajado con MVC solo cuando inicié

Carlos Esteban León Pinilla

student•

En los templates?, según lo entiendo es en las vistas. Ya que los templates es lo que el usuario ve visualmente. Por ende allí no tendría mas lógica que la suficiente para renderizar info. La lógica pesada estaría en las vistas, pero realmente en servicios. Que luego son llamados en las vistas para posteriormente ser pasada a los templates o hacer algo con los modelos...

Gonzalo Ceron Denetro

student•

Django esta basado en el Modelo Vista Controlador (MVC), consiste en cualquier aplicación dividirla en tres módulos, modelo, vista y controlador:

Modelo: Se encarga de gestionar los datos, de obtener la información de una base de datos
Vista: Encargado de mostrar la información al usuario, con lo que interactúa el usuario.
Controlador: Gestiona las comunicaciones entre la vista y el modelo.

Como funciona es que un usuario hace una petición desde la vista, puede hacerlo digamos desde un formulario web, esa petición es registrado por el controlador, el controlador el recibir la información demanda datos al modelo que pueden estar en una base de datos, el modelo le pasa la información al controlador y lo muestra en la vista.

Esa es la filosofía que ocupa, como lo llama Django es MTV (Model Template View) View es el controlador y Template es la vista.

Angelo Mauricio Flores Soria

student•

Tengo una consulta.

En el modelo MVT se informa que la VISTA actúa como un conector.

Entonces ¿Es en la vista donde se deben localizar las API?

Platzi

student•

La vista se encarga de buscar datos y devolvérselos al template. Las APIs no se mencionan explícitamente en este contexto.

César Ernesto Rivas Martínez

student•

Para los que conocen o estan mas familiarizados con MVC es lo mismo pero con otro nombre

Miguel Angel Reyes Moreno

student•

Explicando con IA y mostrando la comparación con la arquitectura "MVC":

Arquitectura MVT de Django: Una Explicación Sencilla

Django utiliza un patrón de arquitectura llamado MVT (Model-View-Template), que es una variación del conocido patrón MVC (Model-View-Controller). Vamos a entender cada componente y cómo interactúan entre sí:

Model (Modelo)

El Modelo representa la estructura de datos de tu aplicación:

Define las tablas de la base de datos como clases de Python
Cada clase de modelo se convierte en una tabla en la base de datos
Cada atributo de la clase se convierte en una columna de la tabla
Maneja la lógica relacionada con los datos: validación, relaciones, consultas, etc.

# Ejemplo de un modelo class Producto(models.Model): nombre = models.CharField(max_length=100) precio = models.DecimalField(max_digits=10, decimal_places=2) descripcion = models.TextField() fecha_creacion = models.DateTimeField(auto_now_add=True)

View (Vista)

La Vista procesa las solicitudes del usuario y devuelve respuestas:

Recibe peticiones HTTP (GET, POST, etc.)
Interactúa con el Modelo para obtener o modificar datos
Prepara los datos para que sean presentados por el Template
Devuelve una respuesta HTTP (HTML, JSON, redirect, etc.)

# Ejemplo de una vista def lista_productos(request): productos = Producto.objects.all() return render(request, 'productos/lista.html', {'productos': productos})

Template (Plantilla)

El Template es responsable de la presentación visual:

Define cómo se mostrarán los datos al usuario
Es un archivo HTML con sintaxis especial de Django
Permite insertar datos dinámicos en el HTML
Puede incluir lógica de presentación simple (bucles, condiciones, etc.)

<h2>Lista de Productos</h2> <ul> {% for producto in productos %} <li>{{ producto.nombre }} - ${{ producto.precio }}</li> {% endfor %} </ul>

Flujo de trabajo

El usuario hace una petición a una URL
Django usa el archivo urls.py para determinar qué Vista debe manejar la petición
La Vista procesa la petición, interactúa con el Modelo si es necesario
La Vista pasa los datos a un Template
El Template renderiza los datos en HTML
La Vista devuelve el HTML como respuesta al navegador

A diferencia del MVC tradicional, en Django:

La "Vista" funciona como un "Controlador"
El "Template" funciona como la "Vista"
El framework mismo maneja parte de lo que sería el "Controlador"

Esta arquitectura permite una separación clara de responsabilidades, lo que hace que el código sea más organizado, mantenible y escalable.

Ray Trápala

student•

Para un método GET, POST, PUT/PATCH en Django, los flujos son los siguientes:

GET:
- El cliente envía una solicitud a la vista.
- La vista consulta el modelo para obtener los datos.
- La vista pasa esos datos al template.
- El template renderiza y devuelve la respuesta al cliente.
POST:
- El cliente envía datos al servidor a través de un formulario.
- La vista recibe la solicitud, valida los datos y los guarda en el modelo.
- Redirige o responde con un mensaje de éxito.
PUT/PATCH:
- Similar a POST, pero se envían datos para actualizar un recurso existente.
- La vista busca el objeto en el modelo, actualiza los campos necesarios y guarda los cambios.
- Responde al cliente con el estado de la operación.

Estos flujos son clave para manejar interacciones en aplicaciones Django.

Ray Trápala

student•

La pregunta fue

Ejemplifica los flujos del modelo MVT para métodos GET, POST , PUT/PATCH

Ray Trápala

student•

Para un proyecto robusto en Django, es recomendable seguir la arquitectura de "separación de preocupaciones". Esto significa que debes organizar tus archivos de manera que la lógica de negocio esté separada del modelo de datos. Una estructura común de carpetas podría ser:

/mi_proyecto
    /app
        /migrations
        /models
            - __init__.py
            - user.py
            - product.py
        /services
            - __init__.py
            - user_service.py
            - product_service.py
        /views
            - __init__.py
            - user_views.py
            - product_views.py
        /templates
        /static
    /settings.py
    /urls.py
    /wsgi.py

En esta estructura, models solo contiene las definiciones de los modelos, mientras que services contiene la lógica de negocio que interactúa con esos modelos. De esta manera, tu código será más limpio, mantenible y escalable.

Ray Trápala

student•

En el patrón MVT de Django, el modelo maneja la lógica de negocio y la conexión a la base de datos. Aunque puede parecer una mala práctica tener esta conexión directa, Django está diseñado para facilitar la gestión de datos y reducir la complejidad al integrar ambas responsabilidades. Sin embargo, en aplicaciones más complejas, puede ser beneficioso implementar una capa de servicios que separe la lógica de negocio de la manipulación directa de la base de datos. Esto mejora la organización del código y facilita el mantenimiento y las pruebas.

Kenet Andrés Chungandro Montenegro

student•

Se me hizo un poco extraña la definición propuesta en el video para MVT ya que según la documentación, el Modelo representa la estructura de los datos, son clases que representan las tablas de mi base de datos. Por otro lado la Vista se encarga de encapsular la lógica responsable de procesar la solicitud del usuario y devolver la respuesta y el Template proporciona una sintaxis intuitiva para el diseñador que permite representar la información que se presenta al usuario.

Gildder Guerrero Ramirez

student•

Principales Diferencias:

Rol de la Vista: La principal diferencia radica en el rol de la vista. En MVC, la vista es más pasiva, simplemente mostrando los datos que le proporciona el controlador. En MVT, la vista es más activa, ya que define cómo se renderizarán los datos y, en cierto modo, también controla el flujo.
Lógica de Negocio: En MVC, la lógica de negocio se concentra en el controlador. En MVT, parte de la lógica de negocio puede estar en la vista, especialmente cuando se trata de decidir qué datos mostrar y cómo.
Flujo de Datos: En MVC, el controlador suele ser el punto central donde se procesan las solicitudes y se actualizan los datos. En MVT, el flujo de datos puede ser más directo entre la vista y el modelo.

Jorge Miranda Zúñiga

student•

MVT (Model-View-Template) es la arquitectura de Django que organiza el desarrollo de aplicaciones web.

Model: Se encarga de la lógica de datos y de cómo se guardan y procesan. Define la estructura de datos y las relaciones entre ellos.
View: Actúa como intermediaria, manejando la lógica de negocio y el flujo de datos. Recibe las solicitudes del usuario, interactúa con el modelo y decide qué datos enviar al template.
Template: Es la parte visual. Se encarga de presentar los datos al usuario, usando HTML y CSS, permitiendo la creación de una interfaz atractiva.

Este flujo asegura una separación de responsabilidades, facilitando la reutilización y el mantenimiento del código.

Francisco Franco

student•

equivalente a MVC, muy interesante

Antonio Demarco Bonino

student•

Resumen:

Modelo (Model): Define cómo se almacenan los datos en la base de datos.
Vista (View): Maneja la lógica de negocio y recibe las solicitudes de los usuarios.
Plantilla (Template): Genera la presentación visual, convirtiendo los datos en HTML u otros formatos.

Mario Alexander Vargas Celis

student•

Django es un framework de desarrollo web en Python que sigue el patrón de diseño **MTV (Model-Template-View)**, una variante del conocido patrón **MVC (Model-View-Controller)**. Aquí te explico cómo se organiza la arquitectura de Django:

### 1. **Modelos (Models)**

- Representan la estructura de datos de tu aplicación. Los modelos en Django se definen como clases de Python que heredan de django.db.models.Model. Cada modelo se traduce en una tabla en la base de datos, y cada instancia del modelo representa una fila en esa tabla.

- Aquí defines los campos y comportamientos de los datos que deseas almacenar, como los tipos de datos y relaciones entre modelos.

### 2. **Plantillas (Templates)**

- Son archivos HTML que definen la presentación de los datos. Django usa un sistema de plantillas propio que permite insertar contenido dinámico, como variables y estructuras de control, en los archivos HTML.

- Las plantillas son responsables de cómo se renderizan los datos en el navegador del usuario.

### 3. **Vistas (Views)**

- Las vistas son funciones o clases que manejan la lógica de la aplicación. Son responsables de recibir una solicitud HTTP, interactuar con los modelos para obtener los datos necesarios y devolver una respuesta HTTP adecuada (como una página HTML, un JSON, etc.).

- Las vistas en Django se asocian a URL específicas a través del archivo urls.py.

### 4. **Controlador (Controller)**

- En el caso de Django, el controlador no es un componente explícito como en el patrón MVC tradicional. La lógica del controlador se divide entre las vistas y el sistema de despacho de URLs (urls.py), que asocia las URLs de la aplicación con las vistas correspondientes.

### 5. **URL Dispatcher**

- El archivo urls.py es donde defines las rutas (URLs) de tu aplicación. Aquí asocias cada URL con una vista específica. Django utiliza un sistema de expresiones regulares para esta asociación.

### 6. **Migrations**

- Django incluye un sistema de migraciones para gestionar los cambios en la estructura de la base de datos. Las migraciones son archivos generados automáticamente o manualmente que Django utiliza para sincronizar el esquema de la base de datos con los modelos definidos en el código.

### 7. **Admin Interface**

- Django ofrece un panel de administración listo para usar que permite a los desarrolladores y administradores gestionar los datos de la aplicación sin necesidad de crear interfaces específicas.

### 8. **Middlewares**

- Son componentes que procesan las solicitudes HTTP antes de que lleguen a las vistas o después de que las respuestas se envíen al cliente. Puedes utilizarlos para tareas como autenticación, manejo de sesiones, o gestión de errores.

### 9. **Formularios (Forms)**

- Django tiene un sistema de formularios que facilita la creación, validación y procesamiento de formularios HTML. Los formularios pueden estar vinculados a modelos (ModelForms) para una integración más sencilla con la base de datos.

### Ejemplo de Flujo en Django:

1. El usuario envía una solicitud a una URL.

2. El **URL dispatcher** dirige la solicitud a la vista adecuada.

3. La **vista** interactúa con los **modelos** para obtener o manipular datos.

4. La vista pasa los datos a una **plantilla** para su renderización.

5. La plantilla genera una respuesta HTML que se envía de vuelta al usuario.

Esta arquitectura permite que el desarrollo sea modular y escalable, lo que facilita la creación y mantenimiento de aplicaciones web complejas.

Christopher Andrés Guano Valencia

student•

Genial clase

Juan Camilo Jimenez V

student•

Flujo de Trabajo de MVT en Django

Solicitud: Un usuario realiza una solicitud HTTP (por ejemplo, accediendo a una URL).

URL Resolver: Django utiliza su sistema de enrutamiento para mapear la URL a una vista específica.

Vista: La vista correspondiente procesa la solicitud, interactúa con el modelo si es necesario, y prepara los datos para la plantilla.

Modelo: Si la vista necesita datos de la base de datos, consulta el modelo correspondiente para obtener o manipular los datos.

Plantilla: La vista pasa los datos a la plantilla, que renderiza el HTML final con los datos dinámicos.

Respuesta: Django devuelve la respuesta HTTP al usuario con el HTML generado.

kolab Linkear

student•

Django es el framework más precioso que tiene Python, su ORM es bastante potente, además al ya tener bastante módulos listos es más fácil manejar la autenticación y si quieres utilizar API ya te da Django Rest Framework