Nahuel Seoane
Oscar Barajas Tavares
Nahuel Seoane
Jenny Aguilar
Carlos Esteban León Pinilla
Menkar Felipe Cantor Molina
Pablo Hurtado
Carlos Esteban León Pinilla
Ivek Martínez Herrera
Carlos Esteban León Pinilla
Mario Alexander Vargas Celis
Kenet Andrés Chungandro Montenegro
César Ernesto Rivas Martínez
Gonzalo Ceron Denetro
Angelo Mauricio Flores Soria
Platzi
Miguel Angel Reyes Moreno
Ray Trápala
Ray Trápala
Ray Trápala
Ray Trápala
Gildder Guerrero Ramirez
Jorge Miranda Zúñiga
Francisco Franco
Antonio Demarco Bonino
Christopher Andrés Guano Valencia
Juan Camilo Jimenez V
kolab Linkear
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í.
Juan, ya está disponible el resumen.
@gndx muchas gracias
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.
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.
Si eso fue algo que me genero mucha confusion debido a que en MVT la vista se comporta como un controlador.
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
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:
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 😅
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é
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...
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.
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.
Para los que conocen o estan mas familiarizados con MVC es lo mismo pero con otro nombre
Django esta basado en el Modelo Vista Controlador (MVC), consiste en cualquier aplicación dividirla en tres módulos, modelo, vista y controlador:
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.
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?
La vista se encarga de buscar datos y devolvérselos al template. Las APIs no se mencionan explícitamente en este contexto.
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:
# 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:
# 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:
<!-- Ejemplo de un template --> <h2>Lista de Productos</h2> <ul> {% for producto in productos %} <li>{{ producto.nombre }} - ${{ producto.precio }}</li> {% endfor %} </ul>
Flujo de trabajo
urls.py para determinar qué Vista debe manejar la peticiónA diferencia del MVC tradicional, en Django:
Esta arquitectura permite una separación clara de responsabilidades, lo que hace que el código sea más organizado, mantenible y escalable.
Para un método GET, POST, PUT/PATCH en Django, los flujos son los siguientes:
GET:
POST:
PUT/PATCH:
Estos flujos son clave para manejar interacciones en aplicaciones Django.
La pregunta fue
Ejemplifica los flujos del modelo MVT para métodos GET, POST , PUT/PATCH
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.
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.
Principales Diferencias:
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.
equivalente a MVC, muy interesante
Resumen:
Genial clase
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.
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