Estructura de archivos y directorios

Al crear un nuevo proyecto Django con el comando django-admin startproject, se genera una estructura de archivos y directorios que constituye la base de la aplicación.

La estructura inicial de un proyecto Django es la siguiente:

mi_proyecto/
    manage.py
    mi_proyecto/
        __init__.py
        settings.py
        urls.py
        asgi.py
        wsgi.py

• manage.py: Es una herramienta de línea de comandos que permite interactuar con el proyecto Django. Con este archivo, se pueden ejecutar comandos como iniciar el servidor de desarrollo, realizar migraciones o crear aplicaciones.
• Directorio mi_proyecto/: Contiene los archivos de configuración y es el paquete principal de la aplicación.
• __init__.py: Indica a Python que este directorio debe tratarse como un paquete. Aunque puede estar vacío, es necesario para el correcto funcionamiento del paquete.
• settings.py: Archivo de configuración del proyecto. Aquí se definen ajustes como la base de datos, aplicaciones instaladas, configuraciones de seguridad y otros parámetros globales.
• urls.py: Contiene las rutas URL del proyecto. Define cómo se distribuyen las solicitudes entrantes entre las diferentes aplicaciones y vistas.
• asgi.py y wsgi.py: Son puntos de entrada para los servidores de aplicaciones ASGI y WSGI, respectivamente. Permiten que Django se comunique con el servidor web.

Al crear una nueva aplicación dentro del proyecto mediante python manage.py startapp mi_app, se añade la siguiente estructura:

mi_app/
    __init__.py
    admin.py
    apps.py
    models.py
    tests.py
    views.py
    migrations/
        __init__.py

• __init__.py: Similar al anterior, declara que mi_app es un paquete Python.
• admin.py: Archivo donde se registran los modelos para que sean gestionables desde el sitio de administración de Django.
• apps.py: Contiene la configuración de la aplicación. Define la clase de configuración que registra la aplicación en el proyecto.
• models.py: Archivo destinado a definir los modelos de datos de la aplicación. Los modelos representan las entidades y estructuras que se almacenarán en la base de datos.
• views.py: Aquí se escriben las vistas de la aplicación, que controlan la lógica y respuesta a las solicitudes HTTP.
• tests.py: Archivo para escribir los tests automatizados de la aplicación, esenciales para garantizar la calidad y correcto funcionamiento del código.
• Directorio migrations/: Almacena las migraciones de base de datos que se generan al modificar los modelos. Las migraciones permiten sincronizar los cambios en los modelos con la estructura de la base de datos.

Además, es común encontrar otros archivos y directorios según las necesidades del proyecto:

• urls.py: Contiene las rutas URL de la aplicación. Funciona de manera idéntica al que se encuentra en el proyecto.
• static/: Directorio para archivos estáticos como imágenes, hojas de estilo CSS y scripts JavaScript.
• templates/: Contiene las plantillas HTML que renderizan las vistas.

Organizar adecuadamente los archivos y directorios facilita la mantenibilidad y escalabilidad del proyecto. Seguir las convenciones establecidas por Django ayuda a que todo el equipo de desarrollo trabaje de manera coherente.

Separación de responsabilidades

En el desarrollo de aplicaciones con Django, es esencial mantener una separación de responsabilidades clara entre los distintos componentes del proyecto. Esto facilita la mantenibilidad y escalabilidad de la aplicación, permitiendo que diferentes desarrolladores trabajen en paralelo sin interferir en el trabajo de los demás.

Django adopta el patrón Modelo-Vista-Plantilla (MVT), que distribuye la lógica de la siguiente manera:

• Modelos: Definen la estructura de datos y las operaciones asociadas a ellos. Se ubican en el archivo models.py y representan las entidades del negocio mediante clases que heredan de django.db.models.Model.
• Vistas: Contienen la lógica de negocio y determinan qué datos se entregan al usuario. Las vistas, definidas en views.py, procesan las solicitudes (requests), interactúan con los modelos y devuelven respuestas (responses).
• Plantillas: Gestionan la presentación de la información. Ubicadas en el directorio templates/, las plantillas utilizan el lenguaje de plantillas de Django para renderizar contenido dinámico en formato HTML.
• URLs: Definen el enrutamiento de las solicitudes a las vistas correspondientes. En urls.py, se establecen las rutas que direccionan las peticiones HTTP a las funciones o clases de vista adecuadas.
• Formularios: Manejan la entrada de datos del usuario y su validación. Django proporciona una biblioteca de formularios que facilita la creación y gestión de formularios web de manera segura.
• Archivos estáticos: Incluyen recursos como imágenes, hojas de estilo CSS y scripts JavaScript. Se organizan en el directorio static/ para su fácil acceso y gestión.
• Aplicaciones: Un proyecto Django se compone de una o varias aplicaciones, cada una enfocada en una funcionalidad específica. Esto promueve la modularidad y reutilización del código. Las aplicaciones se registran en el archivo settings.py bajo la clave INSTALLED_APPS.

Por ejemplo, en una aplicación de blog:

• La aplicación posts gestionará todo lo relacionado con las publicaciones.
• El modelo Post representará cada entrada del blog, con campos como título, contenido y fecha.
• Las vistas controlarán la lógica para mostrar listas de publicaciones o detalles de una entrada específica.
• Las plantillas presentarán el contenido al usuario de forma atractiva y estructurada.
• Las URLs conectarán las rutas como /blog/ o /blog/post/1/ con las vistas correspondientes.

Esta clara separación permite que, por ejemplo, un desarrollador pueda trabajar en la mejora de las plantillas sin afectar a quienes están modificando los modelos o las vistas. Además, facilita las pruebas y el mantenimiento, ya que cada componente tiene una responsabilidad bien definida.

Qué son los modelos, vistas, plantillas, rutas, apps, etc

En Django, es esencial comprender los componentes fundamentales que conforman un proyecto: modelos, vistas, plantillas, rutas y aplicaciones. Cada uno desempeña un papel específico en el desarrollo de aplicaciones web robustas y escalables.

Las aplicaciones son paquetes modulares que encapsulan funcionalidades específicas. Facilitan la organización del código y su reutilización en otros proyectos. Para crear una nueva aplicación, se utiliza el comando:

python manage.py startapp autores

Los modelos representan la estructura de datos y se definen como clases en models.py. Son el vínculo directo con la base de datos y permiten interactuar con los datos de manera abstracta. Por ejemplo, un modelo para gestionar autores podría ser:

from django.db import models

class Autor(models.Model):
    nombre = models.CharField(max_length=100)
    apellido = models.CharField(max_length=100)
    fecha_nacimiento = models.DateField()

    def nombre_completo(self):
        return f"{self.nombre} {self.apellido}"

Los modelos pueden incluir métodos personalizados, como nombre_completo, para agregar lógica específica relacionada con los datos.

Las vistas controlan la lógica de presentación y procesamiento de solicitudes. En views.py, se definen funciones o clases que reciben una petición HTTP y devuelven una respuesta. Por ejemplo, una vista basada en clase para detallar un autor:

from django.views.generic.detail import DetailView
from .models import Autor

class AutorDetalleView(DetailView):
    model = Autor
    template_name = 'detalle.html'

Esta vista utiliza la Generic View DetailView para simplificar la implementación, especificando el modelo y la plantilla a utilizar.

Las plantillas son archivos que definen la presentación visual de los datos. Utilizan el lenguaje de plantillas de Jinja2, permitiendo la inserción de variables y etiquetas. Un fragmento de la plantilla detalle.html podría ser:

<h2>{{ autor.nombre_completo }}</h2>
<p>Fecha de nacimiento: {{ autor.fecha_nacimiento }}</p>

Aquí, se accede al método nombre_completo del modelo para mostrar el nombre completo del autor.

Las rutas o URLconf definen el mapeo entre las URLs y las vistas correspondientes. Existen dos maneras principales de definir rutas en Django:

1. Definiendo rutas directamente en el archivo urls.py del proyecto

Esta es la forma más sencilla de definir rutas. Se hace directamente en el archivo urls.py del proyecto:

from django.urls import path
from autores.views import AutorDetalleView

urlpatterns = [
    path('autor/<int:pk>/', AutorDetalleView.as_view(), name='autor_detalle'),
]

En este caso, todas las rutas están centralizadas en el archivo principal del proyecto.

2. Definiendo rutas en un archivo urls.py dentro de cada aplicación

Este método es más modular y escalable, ya que permite que cada aplicación gestione sus propias rutas. En el archivo urls.py de la aplicación autores, se definen las rutas específicas de esa app:

# autores/urls.py
from django.urls import path
from .views import AutorDetalleView

urlpatterns = [
    path('detalle/<int:pk>/', AutorDetalleView.as_view(), name='autor_detalle'),
]

Luego, estas rutas se incluyen en el archivo urls.py del proyecto principal:

# urls.py del proyecto principal
from django.urls import path, include

urlpatterns = [
    path('autores/', include('autores.urls')),
]

Con este enfoque, la estructura de rutas es más clara, especialmente cuando el proyecto crece y se agregan nuevas aplicaciones.

En ambos casos, se captura el parámetro pk (clave primaria) y se pasa a la vista para mostrar el detalle del autor correspondiente.

Por último, es necesario registrar la aplicación en settings.py añadiéndola a la lista INSTALLED_APPS:

INSTALLED_APPS = [
    ...
    'autores',
]

La interacción entre estos componentes se da de la siguiente manera:

1. Solicitud: Un usuario realiza una petición a una URL específica.
2. Enrutamiento: Django utiliza el archivo urls.py para encontrar la vista asociada a esa URL.
3. Vista: La vista procesa la solicitud, interactúa con los modelos para obtener o manipular datos y decide qué respuesta generar.
4. Modelo: Si es necesario, la vista consulta o modifica los datos a través de los modelos, utilizando consultas ORM.
5. Plantilla: La vista renderiza una plantilla, pasando un contexto con los datos necesarios.
6. Respuesta: Se devuelve el contenido generado al navegador del usuario.

Esta arquitectura permite una separación clara entre la lógica de negocio, la manipulación de datos y la presentación, lo que mejora la mantenibilidad y escalabilidad del proyecto.

Configuraciones de entorno de desarrollo vs entorno producción

En el desarrollo de aplicaciones con Django, es fundamental comprender las diferencias entre el entorno de desarrollo y el entorno de producción. Configurar adecuadamente cada uno garantiza el correcto funcionamiento de la aplicación y asegura aspectos críticos como el rendimiento y la seguridad.

Django utiliza el archivo settings.py para almacenar todas las configuraciones del proyecto. Sin embargo, es una buena práctica separar las configuraciones específicas de desarrollo y producción en archivos distintos. Por ejemplo, crear un directorio settings/ con los siguientes archivos:

mi_proyecto/
    settings/
        __init__.py
        base.py
        desarrollo.py
        produccion.py

• base.py: Contiene las configuraciones comunes a ambos entornos.
• desarrollo.py: Incluye las configuraciones específicas para el entorno de desarrollo.
• produccion.py: Define las configuraciones para el entorno de producción.

En el archivo __init__.py, se puede establecer qué configuración cargar por defecto:

from .desarrollo import *

En el entorno de desarrollo, se habilitan opciones que facilitan la programación y depuración de la aplicación:

• DEBUG = True: Activa el modo depuración, proporcionando información detallada sobre errores.
• ALLOWED_HOSTS = []: Permite todas las direcciones, útil cuando se trabaja localmente.
• Configuración de la base de datos:

  DATABASES = {
      'default': {
          'ENGINE': 'django.db.backends.sqlite3',
          'NAME': BASE_DIR / 'db.sqlite3',
      }
  }

Utilizar SQLite en desarrollo simplifica el manejo de la base de datos.

Archivos estáticos: Se sirven directamente desde el servidor de desarrollo de Django.

Herramientas de desarrollo: Es común incorporar aplicaciones como django-debug-toolbar para facilitar la depuración.

En el entorno de producción, se deben aplicar configuraciones que optimicen el rendimiento y refuercen la seguridad:

DEBUG = False: Desactiva el modo depuración para evitar que información sensible sea expuesta.

ALLOWED_HOSTS: Especifica los dominios y direcciones IP permitidas. Por ejemplo:

  ALLOWED_HOSTS = ['mi_dominio.com', 'www.mi_dominio.com']

• Configuración de la base de datos:

  DATABASES = {
      'default': {
          'ENGINE': 'django.db.backends.postgresql',
          'NAME': 'mi_base_de_datos',
          'USER': 'mi_usuario',
          'PASSWORD': 'mi_contraseña',
          'HOST': 'localhost',
          'PORT': '5432',
      }
  }

Se recomienda utilizar PostgreSQL o MySQL en producción por su robustez y rendimiento.

Gestión de archivos estáticos: Los archivos estáticos deben ser servidos por un servidor web como Nginx o Apache, no por Django. Es necesario recopilar los archivos estáticos mediante el comando python manage.py collectstatic y configurar el servidor web para servirlos desde STATIC_ROOT.

Configuración del secreto:

SECRET_KEY: En producción, el SECRET_KEY debe ser único y mantenerse en secreto. Nunca debe estar en el código fuente. Se puede cargar desde una variable de entorno:

    import os

    SECRET_KEY = os.environ.get('SECRET_KEY')

• Middleware de seguridad: Activar middlewares como SecurityMiddleware para reforzar la seguridad, incluyendo configuraciones como SECURE_SSL_REDIRECT para forzar el uso de HTTPS.

Para manejar las diferencias entre entornos y mantener seguras las credenciales, es aconsejable utilizar variables de entorno. Herramientas como python-decouple o el módulo estándar os permiten acceder a estas variables.

Ejemplo con python-decouple:

from decouple import config

SECRET_KEY = config('SECRET_KEY')
DEBUG = config('DEBUG', default=False, cast=bool)

Se crean entonces archivos .env específicos para cada entorno:

• En desarrollo (.env.development):

  SECRET_KEY=clave_de_desarrollo
  DEBUG=True

• En producción (.env.production):

  SECRET_KEY=clave_de_producción
  DEBUG=False

En producción, es importante configurar adecuadamente el logging para monitorear la aplicación:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'file': {
            'level': 'DEBUG',
            'class': 'logging.FileHandler',
            'filename': '/ruta/al/log/debug.log',
        },
    },
    'loggers': {
        'django': {
            'handlers': ['file'],
            'level': 'DEBUG',
            'propagate': True,
        },
    },
}

Esto permite registrar eventos y errores en archivos de log, facilitando la detección y solución de problemas.

En producción, se recomienda implementar caching para mejorar el rendimiento. Django soporta múltiples backend de cache, como Memcached o Redis:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.redis.RedisCache',
        'LOCATION': 'redis://127.0.0.1:6379',
    }
}

Además, optimizaciones como la compresión de archivos estáticos y el uso de Content Delivery Networks (CDN) pueden mejorar significativamente la experiencia del usuario.

Las configuraciones para enviar correos electrónicos también difieren entre entornos:

• En desarrollo, se puede utilizar la consola o un backend de correo de prueba:

  EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'

• En producción, es necesario configurar un servidor de correo real:

  EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
  EMAIL_HOST = 'smtp.mi_proveedor.com'
  EMAIL_PORT = 587
  EMAIL_HOST_USER = 'usuario@mi_proveedor.com'
  EMAIL_HOST_PASSWORD = 'mi_contraseña'
  EMAIL_USE_TLS = True

En producción, Django debe ser desplegado utilizando un servidor WSGI o ASGI, como Gunicorn o Uvicorn, en conjunto con un servidor web como Nginx. Esto asegura que la aplicación maneje adecuadamente las conexiones y escale según la demanda.

Mantener una clara distinción entre las configuraciones de desarrollo y producción es crucial para el éxito y seguridad de un proyecto Django. Aplicando estas prácticas, se garantiza que la aplicación sea robusta, segura y esté preparada para operar eficientemente en entornos de producción.