È davvero necessario dividere le cose tra le visualizzazioni e il serializzatore.
Serializzatori
Il Serializer è un oggetto autonomo. Viene utilizzato per convertire un modello Django (o qualsiasi tipo di datastructure Python, in realtà) in una forma serializzata e viceversa. Puoi usarlo come tale, ovunque tu voglia. Non ha nemmeno bisogno di una richiesta HTTP effettiva se non hai bisogno di URI nel tuo output.
La sottoclasse ModelSerializer è un tipo specializzato di Serializer che aggiunge funzionalità "caricamento da modello" e "salva su modello". Il punto di ingresso "Salva su modello" è il metodo save(). Per facilitare l'override, la sua implementazione predefinita delegherà il proprio lavoro al metodo create() o update() del serializzatore, a seconda che stia creando una nuova istanza di modello o aggiornandola.
Lo scopo è la personalizzazione: offre allo sviluppatore l'opzione per sostituire solo il metodo di creazione, solo il metodo di aggiornamento o il comportamento comune. Per esempio, permette di fare questo genere di cose:
def save(self, **kwargs):
# Will be done on every save
kwargs['last_changed'] = timezone.now()
return super().save(**kwargs)
def create(self, instance, data):
# Will only be done if a new object is being created
data['initial_creation'] = timezone.now()
return super().create(instance, data)
Questo è un esempio di base. Qui, il campo last_changed verrà impostato ogni volta che un oggetto viene salvato, sia esso una creazione o un aggiornamento. Come sidenote, probabilmente non vuoi farlo. Cose come l'impostazione dei campi "last_changed" dovrebbero vivere nella vista, non nel serializzatore.
Viewsets
In un luogo completamente diverso, Django RIPOSO forniture quadro Viewsets. Quelli sono una raccolta organizzata di viste, che ruotano attorno all'implementazione di un'API CRUD per un modello. In quanto tale, struttura la funzionalità in un insieme di metodi, ovvero create(), retrieve()/list(), update() e delete().
Il punto principale è: non esiste alcuna connessione tra il metodo create() dello strumento di visualizzazione e il metodo create() del serializzatore.
Accade solo che l'implementazione predefinita dei metodi del viewset utilizza un ModelSerializer e che l'implementazione predefinita del metodo save() delegati che di serializzatore il lavoro ai metodi che hanno lo stesso nome.
A proposito, circa l'esempio last_changed, ecco come si farebbe nella vista:
def perform_create(self, serializer):
now = timezone.now()
serializer.save(initial_creation=now, last_changed=now)
def perform_update(self, serializer):
serializer.save(last_changed=timezone.now())
Questo è funzionalmente equivalente all'esempio precedente, ma vive nel viewset.
Conclusione
Ma torniamo alla tua domanda, la cosa specifica si dovrebbe ignorare dipende da quale oggetto è responsabile per l'attività che si desidera aggiungere.
- Se il comportamento personalizzato è parte del processo di serializzazione, cioè, il processo di conversione dei dati grezzi di nuovo in una vera e propria modello di Django e salvarlo, allora si dovrebbe sostituire i metodi s' il
Serializer.
- Se, d'altra parte, il comportamento personalizzato è specifico per il proprio gruppo di viste, è necessario sovrascrivere i metodi di
Viewset.
Come suggerimento, è possibile porsi la seguente domanda: se uso lo stesso serializzatore in un altro posto (forse un altro viewet), dovrebbe sempre visualizzare tale comportamento?
Grazie per la risposta! È davvero dettagliato e approfondito proprio come quello che voglio. +1 :) – Tim