Formación corporativa en Django

Django ORM

El Object-Relational Mapping (ORM) de Django constituye una de las características más distintivas del framework, proporcionando una interfaz Python elegante para interactuar con bases de datos relacionales. En lugar de escribir consultas SQL directamente, el ORM permite trabajar con objetos Python que representan tablas y registros de la base de datos.

¿Qué es un ORM?

Un ORM actúa como una capa de abstracción entre el código Python y la base de datos. Esta abstracción traduce automáticamente las operaciones realizadas sobre objetos Python en consultas SQL correspondientes, y viceversa.

El ORM de Django ofrece ventajas significativas:

• Independencia de la base de datos: El mismo código funciona con PostgreSQL, MySQL, SQLite u otros motores
• Seguridad integrada: Protección automática contra inyecciones SQL
• Sintaxis pythónica: Operaciones de base de datos expresadas como métodos de objetos Python
• Validación automática: Verificación de tipos y restricciones antes de guardar datos

Modelos: La base del ORM

Los modelos en Django son clases Python que heredan de django.db.models.Model. Cada modelo representa una tabla en la base de datos, mientras que cada atributo del modelo corresponde a un campo de esa tabla.

from django.db import models

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)
    activo = models.BooleanField(default=True)

En este ejemplo, Django creará automáticamente una tabla llamada app_producto (donde app es el nombre de tu aplicación) con los campos correspondientes.

ORM avanzado

El módulo de ORM avanzado profundiza en las herramientas que Django ofrece para consultas sofisticadas y optimización de acceso a datos. Cubre managers personalizados, objetos Q y F, transacciones atómicas y estrategias de carga anticipada con select_related y prefetch_related.

Managers personalizados

Los managers son la interfaz principal entre el modelo y la base de datos. Django proporciona un manager por defecto (objects), pero se pueden crear managers personalizados para encapsular consultas frecuentes:

class ProductoActivoManager(models.Manager):
    def get_queryset(self):
        return super().get_queryset().filter(activo=True)

class Producto(models.Model):
    nombre = models.CharField(max_length=100)
    activo = models.BooleanField(default=True)

    objects = models.Manager()
    activos = ProductoActivoManager()

Objetos Q y F

Los objetos Q permiten construir consultas con operadores lógicos (|, &, ~) para condiciones complejas que no se pueden expresar con filter() encadenado. Los objetos F referencian valores de campos de la base de datos directamente, evitando traer datos a Python para compararlos o actualizarlos.

from django.db.models import Q, F

# Productos caros O destacados
Producto.objects.filter(Q(precio__gt=100) | Q(destacado=True))

# Incrementar precio un 10 % sin traer los datos a Python
Producto.objects.update(precio=F('precio') * 1.10)

Django Templates

Los templates en Django constituyen el componente fundamental para generar contenido HTML dinámico en aplicaciones web. Representan la capa de presentación del patrón Model-View-Template (MVT) que utiliza Django, separando la lógica de negocio del diseño visual.

Un template es esencialmente un archivo HTML que contiene marcadores especiales que Django procesa para insertar datos dinámicos. Esta separación permite que desarrolladores y diseñadores trabajen de forma independiente, manteniendo el código Python alejado del HTML.

Sistema de plantillas de Django

Django incluye su propio motor de plantillas que proporciona una sintaxis simple pero potente para crear contenido dinámico. Este sistema está diseñado para ser seguro por defecto, escapando automáticamente el contenido para prevenir ataques de inyección XSS.

La filosofía del sistema de templates de Django se basa en mantener la lógica mínima dentro de las plantillas. A diferencia de otros sistemas que permiten código Python completo, Django limita intencionalmente las operaciones disponibles para fomentar la separación de responsabilidades.

Sintaxis básica de templates

Los templates de Django utilizan una sintaxis especial con llaves dobles y llaves con porcentajes para distinguir el contenido dinámico del HTML estático:

<!DOCTYPE html>
<html>
<head>
    <title>{{ titulo_pagina }}</title>
</head>
<body>
    <h1>Bienvenido, {{ usuario.nombre }}</h1>
    {% if usuario.es_premium %}
        <p>Tienes acceso premium</p>
    {% endif %}
</body>
</html>

Las variables se encierran entre {{ }} y se evalúan insertando su valor en el HTML final. Las etiquetas de template utilizan {% %} y controlan la lógica de renderizado, como condicionales y bucles.

Vistas y enrutamiento URL

El módulo de vistas y enrutamiento cubre el sistema de URLs de Django con path(), re_path(), include() y namespaces, y las dos aproximaciones principales para procesar peticiones HTTP: vistas basadas en funciones y vistas basadas en clases.

Sistema de enrutamiento URL

Django utiliza un sistema de enrutamiento limpio y expresivo. Las URLs se definen con path() para patrones simples y re_path() para expresiones regulares. La función include() permite organizar las URLs en módulos por aplicación, y reverse() genera URLs a partir del nombre de la vista.

from django.urls import path, include

urlpatterns = [
    path('productos/', include('productos.urls', namespace='productos')),
    path('api/', include('api.urls')),
]

Vistas basadas en funciones

Las vistas funcionales son funciones Python que reciben un HttpRequest y devuelven un HttpResponse. Los atajos render(), redirect() y get_object_or_404() simplifican las operaciones más habituales. Los decoradores @login_required y @require_http_methods añaden comportamiento transversal.

Formularios

El módulo de formularios abarca el sistema completo de manejo de datos de entrada en Django: desde la clase Form y ModelForm hasta la validación avanzada, los widgets personalizados, los formsets y la subida de archivos.

Form y ModelForm

Django proporciona dos clases base para formularios. Form define los campos manualmente, mientras que ModelForm los genera automáticamente a partir de un modelo. La clase interna Meta controla qué campos incluir, los widgets y las etiquetas.

class ProductoForm(forms.ModelForm):
    class Meta:
        model = Producto
        fields = ['nombre', 'precio', 'categoria']
        widgets = {
            'nombre': forms.TextInput(attrs={'class': 'form-control'}),
        }

Validación

La validación opera en múltiples niveles: validadores de campo (clean_nombre()), validación cruzada entre campos en el método clean(), y validadores reutilizables con RegexValidator y MinValueValidator. El método is_valid() ejecuta todos los niveles y almacena los errores en form.errors.

Autenticación y autorización

El módulo de autenticación cubre el sistema completo de gestión de identidad y acceso en Django: modelo User y su extensión con AbstractUser, vistas de login/logout, registro de usuarios, permisos y grupos, decoradores y mixins de autenticación, y el framework de sesiones.

Modelo User y extensiones

Django incluye un modelo User con campos username, email, password, first_name, last_name y campos de permisos. Para proyectos nuevos es recomendable definir desde el inicio un modelo personalizado con AbstractUser y configurar AUTH_USER_MODEL en settings.py para evitar migraciones complicadas más adelante.

Login, logout y registro

Django proporciona vistas preconstruidas LoginView y LogoutView con soporte para redirecciones y plantillas personalizables. La función authenticate() verifica credenciales y login() inicia la sesión. El formulario UserCreationForm facilita el registro de nuevos usuarios.

Panel de administración

El módulo de administración cubre la configuración y personalización del panel de administración de Django: registro de modelos, clase ModelAdmin, fieldsets, filtros, búsqueda, inlines para relaciones y acciones personalizadas en lote.

Configuración inicial

El panel de administración se activa con django.contrib.admin en INSTALLED_APPS. Se registran modelos con el decorador @admin.register(Modelo) o con admin.site.register(Modelo, ModelAdminClass). El superusuario se crea con python manage.py createsuperuser.

ModelAdmin

La clase ModelAdmin controla cómo se muestra y edita cada modelo en el panel. Los atributos principales incluyen list_display, list_filter, search_fields, ordering, list_editable y list_per_page. Para los formularios de edición, fieldsets organiza los campos en secciones, y readonly_fields define campos no editables.

@admin.register(Producto)
class ProductoAdmin(admin.ModelAdmin):
    list_display = ['nombre', 'precio', 'categoria', 'activo']
    list_filter = ['categoria', 'activo']
    search_fields = ['nombre', 'descripcion']
    list_per_page = 25

API REST con Django REST Framework

Django REST Framework (DRF) es una biblioteca que extiende las capacidades de Django para crear APIs REST de forma sencilla y eficiente. Mientras que Django está diseñado principalmente para aplicaciones web tradicionales que renderizan HTML, DRF nos permite construir servicios web que intercambian datos en formato JSON, facilitando la comunicación entre aplicaciones frontend y backend.

¿Qué es una API REST?

Una API REST es un conjunto de reglas que permite a diferentes aplicaciones comunicarse entre sí a través de HTTP. En lugar de devolver páginas HTML completas, una API REST devuelve datos estructurados (normalmente en JSON) que pueden ser consumidos por aplicaciones móviles, sitios web con JavaScript, o cualquier otro cliente que necesite acceder a la información.

Los principios fundamentales de REST incluyen el uso de métodos HTTP estándar:

• GET: Para obtener datos
• POST: Para crear nuevos recursos
• PUT/PATCH: Para actualizar recursos existentes
• DELETE: Para eliminar recursos

Instalación y configuración inicial

Para comenzar a trabajar con Django REST Framework, necesitamos instalarlo en nuestro proyecto Django existente:

pip install djangorestframework

Una vez instalado, debemos agregarlo a la lista de aplicaciones instaladas en settings.py:

INSTALLED_APPS = [
    'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'rest_framework',  # Agregamos DRF
    'tu_app',
]

Autenticación, paginación y filtrado

El módulo intermedio de DRF añade a la API CRUD las piezas que toda API real necesita: autenticación con SessionAuthentication y TokenAuthentication, paginación lista para usar y filtrado declarativo con django-filter.

Instalación y configuración

pip install djangorestframework djangorestframework-simplejwt django-filter

DRF se activa añadiendo 'rest_framework' a INSTALLED_APPS y configurando REST_FRAMEWORK en settings.py con los valores por defecto de autenticación, permisos y paginación.

Serializadores

Los serializadores transforman instancias de modelos en JSON y viceversa. ModelSerializer genera los campos automáticamente a partir del modelo. Los serializadores anidados, SerializerMethodField y la validación personalizada (validate_campo, validate) permiten adaptar la representación a las necesidades de la API.

Middleware, señales y caché

El módulo de middleware, señales y caché cubre las capas transversales de una aplicación Django: middleware personalizado para interceptar peticiones y respuestas, señales para comunicación desacoplada entre componentes, framework de caché con Redis, envío de emails y comandos personalizados de manage.py.

Middleware

Los middleware son clases que se ejecutan en orden para cada petición y su respuesta. Django incluye middleware de seguridad, sesiones, autenticación y CSRF. Un middleware personalizado implementa __init__ y __call__, e intercepta tanto la petición entrante como la respuesta saliente para añadir funcionalidad transversal como logging, auditoría o limitación de tasa.

Señales

Las señales permiten que componentes desacoplados de la aplicación se comuniquen cuando ocurren determinados eventos. Las señales predefinidas más usadas son pre_save, post_save, pre_delete y post_delete. El decorador @receiver conecta una función manejadora a una señal de forma declarativa.

from django.db.models.signals import post_save
from django.dispatch import receiver

@receiver(post_save, sender=Usuario)
def crear_perfil(sender, instance, created, **kwargs):
    if created:
        Perfil.objects.create(usuario=instance)

Testing y despliegue

El módulo de testing y despliegue cierra el ciclo de desarrollo de Django: testing unitario y de integración con TestCase, medición de cobertura con Coverage.py, y despliegue en producción con Gunicorn, Nginx, Docker y configuración segura.

Testing unitario

La clase TestCase de Django proporciona una base de datos aislada para cada test, setUp y tearDown, y assertions especializados. Los tests de modelos verifican la lógica de negocio, los formularios comprueban la validación, y los de señales aseguran que los eventos disparan las acciones correctas.

Testing de vistas con Client

El Client de test simula peticiones HTTP sin necesidad de un servidor real. Métodos client.get() y client.post() devuelven respuestas que pueden verificarse con assertContains(), assertRedirects(), assertTemplateUsed() y assertEqual(response.status_code, 200).

class ListaProductosTest(TestCase):
    def test_lista_muestra_productos(self):
        Producto.objects.create(nombre='Test', precio=9.99)
        response = self.client.get(reverse('lista-productos'))
        self.assertEqual(response.status_code, 200)
        self.assertContains(response, 'Test')

Seguridad y arquitectura moderna

El módulo de seguridad y arquitectura cubre las capacidades recientes de Django orientadas a proyectos enterprise: Content Security Policy (CSP) integrada con SECURE_CSP y ContentSecurityPolicyMiddleware, partials en el lenguaje de plantillas para componentes reutilizables y el framework de tareas (django.tasks) para encolar trabajo fuera de la petición HTTP.

Content Security Policy

La CSP es una capa de seguridad que mitiga ataques XSS e inyección de datos. Django permite definir la política directamente en settings.py con SECURE_CSP y aplicarla mediante ContentSecurityPolicyMiddleware. Los nonces generados por petición permiten autorizar scripts y estilos inline de forma segura.

SECURE_CSP = {
    "default-src": ["'self'"],
    "script-src": ["'self'", "'nonce'"],
    "style-src": ["'self'", "'nonce'"],
}

MIDDLEWARE = [
    "django.middleware.security.ContentSecurityPolicyMiddleware",
    # ...
]

Partials en plantillas

Las partials ({% partialdef %} y {% partial %}) permiten definir fragmentos reutilizables dentro de una plantilla y referenciarlos desde otras plantillas con la sintaxis template#nombre. Esta funcionalidad reduce la duplicación de HTML y facilita la composición de interfaces modulares.

Una API REST con ViewSets + Serializers + router ya está lista para funcionar. Pero una API en producción requiere piezas adicionales: documentación automática para integradores, versionado que permita evolucionar sin romper clientes, throttling contra abusos, caching para no ahogar la base de datos y rendimiento sin queries N+1.

Este módulo cubre exactamente esas piezas operativas. Cada lección es una herramienta que un equipo senior aplicaría antes de que un cliente B2B use la API en producción. La autenticación JWT, los permisos avanzados y el testing se cubren en un módulo aparte porque son prerrequisitos de varias técnicas que verás aquí (por ejemplo, el throttling por usuario sólo cobra sentido con autenticación real).

Conceptos clave que aprenderás

Generarás documentación OpenAPI 3.1 automática con drf-spectacular sin mantenerla a mano, con Swagger UI y Redoc, y ejemplos anidados con @extend_schema. Es la puerta de entrada para cualquier integrador y, con ello, la diferencia entre una API amateur y una API profesional.

Versionarás tus APIs con URLPathVersioning, NamespaceVersioning o AcceptHeaderVersioning para evolucionar sin romper clientes. Añadirás throttling con AnonRateThrottle, UserRateThrottle y ScopedRateThrottle para protegerte de abuso, con backend Redis para múltiples workers.

Acelerarás las respuestas con caching en Redis usando cache_page, @method_decorator o el patrón de versión key para invalidación selectiva. Pasarás de responder en 300ms a 5ms para páginas poco cambiantes.

Cerrarás el módulo persiguiendo el problema N+1 con django-silk, django-debug-toolbar y nplusone, aplicando select_related, prefetch_related y Prefetch(to_attr), así como annotate para mover agregados a SQL y CONN_MAX_AGE para connection pooling.

Al terminar este módulo, tu API será documentada, versionada, resistente al abuso y rápida bajo carga real.