Come funzionano i model e l'ORM?

Question

Accepted Answer

Un **model** è una classe Python che definisce la struttura dei tuoi dati: ogni model corrisponde a una tabella del database e ogni attributo a una colonna. L'**ORM (Object-Relational Mapper)** ti permette di interagire con il database usando oggetti e metodi Python invece di scrivere SQL grezzo.

## Definire un model

```python
from django.db import models

class Article(models.Model):
    title = models.CharField(max_length=200)       # → VARCHAR column
    body = models.TextField()                        # → TEXT column
    published = models.BooleanField(default=False)
    created_at = models.DateTimeField(auto_now_add=True)  # set on creation
    views = models.IntegerField(default=0)

def __str__(self):
        return self.title                            # readable representation (admin, shell)
```

Ogni campo del model corrisponde a una colonna del database con un tipo appropriato. L'esecuzione delle migration crea la tabella corrispondente: non scrivi mai tu stesso `CREATE TABLE`.

## CRUD con l'ORM (niente SQL)

```python
# CREATE
article = Article.objects.create(title="Hello", body="...")

# READ — query with Python methods
Article.objects.all()                            # all rows → SELECT *
Article.objects.get(id=1)                         # one row by primary key
Article.objects.filter(published=True)            # WHERE published = true
Article.objects.filter(title__icontains="django") # WHERE title ILIKE '%django%'
Article.objects.exclude(views=0).order_by("-created_at")  # complex queries, chained

# UPDATE
article.title = "Updated"
article.save()
Article.objects.filter(published=False).update(published=True)  # bulk update

# DELETE
article.delete()
```

L'ORM traduce automaticamente queste chiamate Python in SQL. I field lookup (`__icontains`, `__gte`, `__in`, ecc.) esprimono le condizioni WHERE in modo pythonico.

## Perché un ORM? Vantaggi e compromessi

```text
✓ Write database code in Python — no SQL, more readable, less error-prone
✓ Database-agnostic — the same code works on PostgreSQL, MySQL, SQLite
✓ SECURITY — parameterized queries by default → prevents SQL injection
✓ Integrates with migrations, admin, forms (define the model once)
⚠️ Trade-off: can generate inefficient queries (e.g. N+1) if used carelessly —
   sometimes you need select_related/prefetch_related or raw SQL for complex cases
```

## I model sono l'unica fonte di verità (DRY)

```text
One model definition drives: the database schema (migrations), the admin interface,
ModelForms, and serializers (DRF) — define it once, reuse everywhere.
```

## Perché è importante

I model e l'ORM sono centrali in Django: sono il modo in cui definisci e lavori con i dati della tua applicazione, che costituiscono il cuore della maggior parte delle applicazioni web.

Comprenderli è una conoscenza quotidiana essenziale: i model definiscono la struttura dei tuoi dati (mappando le classi alle tabelle e gli attributi alle colonne) e fungono da **unica fonte di verità** che guida lo schema del database, l'interfaccia di admin, i form e i serializer dell'API (la filosofia DRY).

L'ORM ti permette di scrivere le operazioni sul database in **Python pulito e leggibile invece che in SQL**, con importanti vantaggi: portabilità del database (lo stesso codice gira su database diversi), stretta integrazione con il resto di Django e, soprattutto, **sicurezza** (usa per impostazione predefinita query parametrizzate, prevenendo la SQL injection).

Sapere come definire i model con i campi appropriati, eseguire operazioni CRUD ed effettuare query con la sintassi dei lookup dell'ORM è fondamentale per costruire qualsiasi applicazione Django.

Altrettanto importante è la consapevolezza del **compromesso** dell'ORM, ovvero che query comode possono diventare inefficienti (il problema N+1) senza attenzione, il che porta alle tecniche di ottimizzazione.

Il livello model/ORM è dove le applicazioni Django concentrano gran parte della loro logica, rendendolo materiale fondamentale e da padroneggiare.