# Documentazione Django 5.2.8

# Design di filosofie

Questo documento spiega alcuni concetti fondamentali della filosofia Django che gli sviluppatori hanno usato nella creazione del framework. Lo scopo primario è quello di spiegare il passato e guidare verso il futuro.

## !!Complessivamente

### Accoppiamento lasco

Uno degli obiettivi primari dello stack di Django è loose coupling and tight cohesion. I vari layer del framework non dovrebbero «essere a conoscenza» l’uno dell’altro se non strettamente necessario.

Per esempio, il sistema di template non sa nulla delle richieste web, il layer di database non sa nulla di come vengano mostrati i dati ed il sistema delle views non si interessa di quale sistema di template il programmatore utilizzi.

Sebbene Django venga fornito come full stack per convenienza, i pezzi dello stack sono indipendenti uno dall’altro quando possibile.

### Meno codice

Le applicazioni Django dovrebbero usare meno codice possibile; non dovrebbero esserci boilerplate. Django dovrebbe trarre pieno vantaggio delle capacità dinamiche di Python, come l’introspezione.

### Sviluppo rapido

Il punto di utilizzare un framework web nel ventunesimo secolo è rendere gli aspetti noiosi dello sviluppo web veloci. Django dovrebbe permettere uno sviluppo web incredibilmente rapido.

### Non ti ripetere! (DRY – Don’t repeat yourself)

Ogni singolo concetto e/o pezzo di dato dovrebbe vivere in uno ed un solo posto solo. La ridondanza è una cattiva abitudine. La normalizzazione è una buona abitudine.

Il framework, entro limiti ragionevoli, dovrebbe dedurre il più possibile dal meno possibile.

Vedi anche

La discussion of DRY on the Portland Pattern Repository

### Esplicito è meglio di implicito

Questo è un principio primario di Python presente in PEP 20, e significa che Django non dovrebbe essere troppo «magico». La magia non dovrebbe esserci a meno che non ci siano delle valide ragioni. La magia merita di essere usata solo se crea grandi vantaggi non raggiungibili in altri modi, e non è implementata in modo da confondere gli sviluppatori che tentano di imparare come usare una feature.

### Consistenza

Il framework dovrebbe essere consistente a tutti i livelli. La consistenza si applica a tutto, dal low-level (lo stile di codice Python usato) all” high-level («l’esperienza» di uso di Django.)

## Modelli

### Esplicito è meglio di implicito

I campi non dovrebbero dare per scontati certi comportamenti basati solo sul nome del campo. Questo richiederebbe troppa conoscenza del sistema ed è incline ad errori. Invece, i comportamenti dovrebbero essere basati su argomenti chiave e, in alcuni casi, sul tipo del campo.

### Includere tutte le logiche di dominio rilevanti

I modelli dovrebbero incapsulare ogni aspetto di un «oggetto» seguendo il pattern design Active Record definito da Martin Fowler

Per questo motivo, i dati sono rappresentati da un modello e dalle informazioni su di essi (un nome di facile lettura, opzioni come l’ordinamento di default, ecc…) sono definiti nella classe modello; tutte le informazioni necessarie per comprendere un modello dovrebbero trovarsi nel modello.

## Database API

I principali obiettivi delle API del database sono:

### Efficenza SQL

Dovrebbe eseguire dichiarazioni SQL il minor numero di volte possibile, ed ottimizzare le dichiarazioni internamente.

Per questo è necessario che gli sviluppatori chiamino `save()` esplicitamente, piuttosto che lasciare al framework il compito di salvarle in background.

Anche per questo motivo esistono i metodi `select_related()` di `QuerySet`. È un booster di performance opzionale per i casi più comuni di selezioni di «ogni oggetto correlato».

### Sintassi potente e concisa

Le API del database dovrebbero permettere dichiarazioni ricche ed espressive con la minima sintassi possibile. Non dovrebbero fare affidamento sulle importazioni di altri moduli o su oggetti helper.

Le Join dovrebbero essere eseguite automaticamente, in background, quando necessario.

Ogni oggetto dovrebbe essere capace di accedere ad ogni oggetto relazionato, globalmente. Questo tipo di accesso dovrebbe funzionare in entrambi i sensi.

### Opzioni da usare nelle query SQL grezze, quando necessario.

La API per il database dovrebbe capire che è una scorciatoia ma non necessariamente qualcosa di estremamente importante. Il framework dovrebbe rendere semplice scrivere dell” SQL personalizzato - intere espressioni o semplicemente clausole «WHERE» come parametri custom delle chiamate API.

## Design dell’URL

### Accoppiamento lasco

Le URL in una app Django non dovrebbero essere accoppiate al codice Python sottostante. Legare le URL ai nomi di funzioni Python è una cosa brutta e cattiva.

In tal senso, il sistema di URL di Django dovrebbe permettere che URL nella stessa app siano differenti per contesti differenti. Per esempio, un sito potrebbe collocare le storie in `/stories/`, mentre un’altro potrebbe usare `/news/`.

### Flessibilità infinita

Le URL dovrebbero essere il più flessibili possibile. Qualsiasi URL design che possa essere concepito, dovrebbe essere permesso.

### Incoraggiare le best practices

Il framework dovrebbe rendere semplice (o perfino semplicissima), per uno sviluppatore, la creazione di URL belle piuttosto che brutte.

Le estensioni dei file nelle URL delle pagine web dovrebbero essere evitate.

Le virgolette in stile «vignetta» nelle URL meritano di essere punite severamente.

### URL definitive

Tecnicamente, `foo.com/bar` e `foo.com/bar/` sono due URL differenti ed i robot dei motori di ricerca (ed alcuni tool di analisi del traffico) li tratterebbero come pagine diverse. Django dovrebbe fare uno sforzo per «normalizzare» le URL in modo che i robot dei motori di ricerca non cadano in confusione.

Questa è il ragionamento che sta alla base dell’impostazione `APPEND_SLASH`.

## Sistema dei template

### Dividere la logica dalla presentazione

Noi vediamo un sistema di template come un tool che controlla la presentazione e le logiche correlate alla presentazione – e questo è quanto. Il sistema di template non dovrebbe gestire funzionalità che vanno oltre questo obiettivo di base.

### Scoraggiare la ridondanza

La maggior parte dei siti dinamici utilizza uno stile comune a tutto il sito - una intestazione comune, un piè di pagina, una barra di navigazione, ecc. Il sistema di template di Django dovrebbe rendere facile mettere questi elementi in un unico posto, eliminando il codice duplicato.

Questa è la filosofia dietro all” ereditarietà dei template.

### Essere disaccoppiato dall’HTML

Il sistema template non dovrebbe essere strutturato in modo tale da ottenere solo HTML. Dovrebbe essere ugualmente valido per generare anche altri formati basati sul testo o anche solo plain text.

### XML non dovrebbe essere usato per linguaggi di template

L’utilizzo di un motore XML per fare il parse dei template introduce nuovi errori umani nell’editing dei template – ed introduce un livello inaccettabile di overhead nel processamento dei template.

### Ingaggia designer competenti

Il sistema di template non dovrebbe essere progettato in modo da poter mostrare bene i template negli editor WYSIWYG, come ad esempio Dreamweaver. Sarebbe una limitazione troppo grande e non permette alla sintassi di essere bella come è. Django si aspetta che gli autori dei template siano in grado di fare editing direttamente sull’HTML.

### Trattare gli spazi bianchi ovviamente

Il sistema di template non dovrebbe fare magie con gli spazi bianchi. Se un template include spazi bianchi, il sistema dovrebbe trattarli così come tratta il testo – mostrandoli. Ogni spazio bianco che non si trova in un template tag dovrebbe essere mostrato.

### Non inventare un linguaggio di programmazione

La finalità non è quella di inventare un linguaggio di programmazione. Il fine è quello di offrire un buon numero di funzionalità «da programmazione», come il branching ed il looping, essenziali per le decisioni a livello di presentazione. Il :ref:`Linguaggio dei Template di Django (DTL)<template-language-intro> mira ad evitare la logica avanzata.

### Sicurezza e security

Il sistema di template, out of the box, dovrebbe vietare l’iniezione di codice malevolo – come per esempio un comando che cancella record del database.

Questo è un altro motivo per il quale il sistema di template non permette l’utilizzo di codice Python arbitrario.

### Estensibilità

Il sistema di template dovrebbe riconoscere che autori di template avanzati potrebbero voler estendere la sua tecnologia.

Questa è la filosofia che sta dietro ai filtri ed ai template tag personalizzati.

## View

### Semplicità

Scrivere una vista/view dovrebbe essere semplice come scrivere una funzione Python. Gli sviluppatori non dovrebbero preoccuparsi di istanziare una classe quando potrebbe andare bene una funzione.

### Usare oggetti per le richieste

Le viste/views dovrebbero avere accesso ad un oggetto “request” – un oggetto che fornisce metadati sulla richiesta attuale. L’oggetto dovrebbe essere passato direttamente ad una funzione view, piuttosto che lasciare che la funzione view abbia accesso ad una variabile globale con i dati richiesti. Questo rende semplice, pulito e facile, testare la view passando un oggetto request fittizio.

### Accoppiamento lasco

Una view non si dovrebbe curare di quale sistema di template utilizza lo sviluppatore - e nemmeno del fatto che si utilizzi o meno un sistema di template.

### Distinguere tra GET e POST

GET e POST sono distinti; gli sviluppatori dovrebbero espressamente usare l’uno o l’altro. Il framework dovrebbe rendere facile la distinzione di dati GET e POST.

## Cache Framework

Gli obbiettivi primari di Django cache framework sono :

### Meno codice

Una cache dovrebbe essere il più veloce possibile. Quindi, tutto il codice del framework che sta attorno al backend della cache dovrebbe essere assolutamente minimale, specialmente per quanto riguarda le operazioni `get()`.

### Consistenza

La API della cache dovrebbe offrire una interfaccia consistente per tutti i differenti backend di cache.

### Estensibilità

La API della cache dovrebbe essere estendibile al livello di applicazione a seconda delle esigenze dello sviluppatore (per esempio, vedi Cache key transformation)