4.1Web back-end con Django
Lo esencial en 30 segundos
- Django = « baterías incluidas » : ORM (la base se manipula como objetos Python), migraciones (evolución sin SQL manual), admin autogenerado y autenticación incluidos de serie.
- Circuito MVT :
models.py(datos) →urls.py(rutas) →views.py(lógica) → plantilla.html(visualización) ;makemigrations + migratedespués de cada modelo. - Reflejo de Nabil : abrazar las convenciones MVT en lugar de luchar contra ellas — Django impone una estructura exigente al principio, que luego salva el proyecto.
Mini-caso hilado — Nabil expone sus ventas en Argel
Nabil, analista de datos junior en Argel, pasa sus días reenviando el mismo CSV de ventas a sus colegas. Decide construir un mini back-office con Django : un modelo Venta (ciudad, importe, fecha), migraciones que crean la tabla sin SQL y el admin autogenerado donde el equipo consulta y filtra las ventas sin molestarle. En una semana, su CSV semanal se convierte en una aplicación que cada uno consulta solo. Primer hito del hilo : del analista que envía archivos al desarrollador que expone un servicio.
Este mismo caso vuelve en el curso, el esquema, el guion y el reto 48h — y continúa en 4.2, 4.3, 4.4 y 4.5.
1. Django « baterías incluidas » y el MVT
Django es el framework web completo de Python : ofrece de serie la administración (back-office generado), el ORM (la base se manipula como objetos Python), la autenticación (cuentas, permisos) y la seguridad (CSRF, XSS, inyecciones). Su organización se llama MVT : el Modelo (models.py) describe los datos, la Vista (views.py) contiene la lógica, la Plantilla (.html) muestra — el enrutado (urls.py) conecta URL y vistas. Como Nabil, abrazamos estas convenciones : exigentes al principio, salvadoras después.
2. ORM, migraciones y admin : el trío productivo
El ORM traduce vuestras clases Python en tablas : class Vente(models.Model) con campos (CharField, DecimalField, DateField) se convierte en una tabla, y Vente.objects.filter(ville="Alger") sustituye al SELECT — sin SQL manual. Las migraciones versionan cada cambio del modelo : python manage.py makemigrations y luego migrate, y la base evoluciona limpiamente, en equipo como en producción. El admin (activado con createsuperuser, en /admin) ofrece desde los primeros minutos un back-office para consultar y corregir los datos. Nabil consigue así su primer servicio al equipo.
¿Cuándo elegir Django? Páginas servidas en el servidor + cuentas + back-office → Django. JSON puro consumido por un front separado → mejor una API ligera (ver 4.2). E incluso con el ORM, unas bases de SQL siguen siendo útiles para optimizar y entender lo que pasa bajo el capó.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Las ventas de Nabil en MVT
Los cuatro gestos de Nabil, con las API reales :
models.py → class Vente(models.Model): ville, montant, date
shell → makemigrations + migrate (tabla creada, sin SQL)
urls.py → path('ventes/', vues.liste_ventes)
views.py → Vente.objects.filter(ville="Alger") → templateLectura : modelo, ruta, vista, plantilla — cada uno en su lugar.
Lección : el admin expone estas ventas sin programar un back-office.
Vocabulario de la sección
- Django
- Framework web Python completo (« baterías incluidas ») : admin, ORM, autenticación y seguridad incluidos de origen.
Ejemplo sencillo: Nabil construye allí su back-office de ventas en una semana.
Lo que no es: una acumulación de scripts sin estructura ni cuentas.
Reflejo: ¿páginas + cuentas + admin? pensar primero en Django.
- MVT (Modelo-Vista-Plantilla)
- Organización del código Django : Modelo (datos), Vista (lógica), Plantilla (visualización HTML), conectados por el enrutado urls.py.
Ejemplo sencillo: Las ventas de Nabil : modelo Vente, vista liste_ventes, plantilla ventes.html.
Lo que no es: un único script que mezcla SQL, lógica y HTML.
Reflejo: para cada archivo, preguntar : ¿dato, lógica o visualización?
- ORM
- Manipulación de la base mediante objetos Python (Vente.objects.filter(...)) en lugar de escribir SQL.
Ejemplo sencillo: Nabil filtra las ventas de Argel sin escribir un SELECT.
Lo que no es: SQL concatenado con variables dentro del código.
Reflejo: leer las consultas generadas cuando una página se ralentiza.
- Migración
- Archivo que traduce los cambios de vuestros modelos en modificaciones de la base (makemigrations + migrate).
Ejemplo sencillo: Nabil añade el campo fecha : una migración hace evolucionar la tabla en todas partes.
Lo que no es: ALTER TABLE hechos a mano en producción.
Reflejo: ningún cambio de estructura fuera de una migración.
En la práctica — En práctica — Descubrir Django y su admin
- En un venv, instalad Django (pip install django) y cread un proyecto : « django-admin startproject monsite », luego una aplicación « python manage.py startapp ventes ».
- Declarad un modelo (p. ej. Vente : ciudad, importe, fecha) y luego lanzad « makemigrations » y « migrate » : observad la tabla creada sin SQL.
- Cread un superusuario (« createsuperuser »), lanzad « runserver » y explorad el admin : añadid y filtrad filas.
- Añadid una URL, una vista que interroga al ORM y una plantilla que muestra la lista.
Guion listo para decir — presentar su back-office (30 s)
« Soy Nabil : nuestras ventas viven en un modelo Django, la base evoluciona con migraciones y el equipo las consulta en el admin sin pedirme ningún CSV. Las URL, las vistas y las plantillas siguen el MVT : cada uno sabe dónde buscar. »
Para decir en reunión de equipo ; mostrad el admin en directo.
Modelo copiar-pegar — mini-app Django (código probado)
# ventes/models.py
from django.db import models
class Vente(models.Model):
ville = models.CharField(max_length=80)
montant = models.DecimalField(max_digits=10, decimal_places=2)
date = models.DateField()
def __str__(self):
return f"{self.ville} — {self.montant}"
# ventes/views.py
from django.shortcuts import render
from .models import Vente
def liste_ventes(request):
ventes = Vente.objects.filter(ville="Alger").order_by("-date")[:20]
return render(request, "ventes/liste.html", {"ventes": ventes})
# ventes/urls.py
from django.urls import path
from . import views
urlpatterns = [
path("ventes/", views.liste_ventes, name="liste-ventes"),
]
# Comandos :
# python manage.py makemigrations && python manage.py migrate
# python manage.py createsuperuser && python manage.py runserver
Primer proyecto
Un modelo + el admin bastan : exponed vuestros datos en una hora antes de programar la menor página.
Aplicación de equipo
Como Nabil : MVT estricto, todo cambio de base en una migración, admin como back-office de respaldo.
Datos existentes
Importad vuestro CSV al ORM una vez (script de importación) y dejad que Django sirva : fin de los archivos circulando.
Hacia una API
¿JSON puro para un front separado? Conservad los modelos Django y añadid una capa API (ver 4.2) en lugar de reescribirlo todo.
✓ Buenas prácticas
- Abrazar las convenciones MVT en lugar de rodearlas.
- Migrar desde el primer modelo, admin desde la primera hora.
- Conservar unas bases de SQL para optimizar el ORM.
✗ Errores frecuentes
- Luchar contra las convenciones del framework.
- Escribir SQL manual en lugar de usar el ORM.
- Tomar Django por una API JSON pura y ligera.
Puntos clave
- DJANGO = framework « BATERÍAS INCLUIDAS » : admin, ORM, autenticación y seguridad incluidos de serie.
- MVT : MODELO (datos) → URL (enrutado) → VISTA (lógica) → PLANTILLA (visualización).
- ORM = base como objetos Python ; MIGRACIONES = evolución sin SQL manual.
- ADMIN autogenerado : back-office desde los primeros minutos. Del analista del CSV al servicio expuesto.
Reto 48h — aplica mañana
Cread 1 proyecto Django con 1 modelo de vuestros propios datos, migrad, explorad el admin y mostrad 1 lista filtrada en una plantilla.
- Puedo citar MVT, ORM, migraciones y admin.
- Sé crear un modelo y migrar sin SQL.
- Tengo 1 página Django que muestra mis datos.
Preguntas frecuentes
Django o Flask/FastAPI : ¿cómo elegir?
Django cuando hace falta una aplicación completa y estructurada : páginas servidas, cuentas, permisos, back-office — todo incluido y coherente, a cambio de abrazar sus convenciones. Flask o FastAPI cuando hace falta un servicio ligero y a medida, típicamente una API JSON consumida por otro cliente (ver 4.2). Nabil lo resume : back-office de equipo → Django ; JSON puro para un front → API.
¿Hay que conocer SQL para usar el ORM de Django?
No al principio : el ORM basta para crear, leer y filtrar. Sí en cuanto crece : entender tablas, índices y consultas generadas para optimizar las páginas lentas, depurar y escribir las consultas complejas que el ORM expresa mal. El ORM + unas bases de SQL = el buen dúo.
¿Por qué se dice que Django es « baterías incluidas »?