Separazione della logica aziendale e dell’accesso ai dati in django

| | | | | | | | | | | | | | | | | |

Sto scrivendo un progetto in Django e vedo che l'80% del codice è nel file models.py. Questo codice crea confusione e, dopo un certo tempo, smetto di capire cosa sta realmente accadendo.

Ecco cosa mi dà fastidio:

  1. Trovo brutto che il mio modello level (che avrebbe dovuto essere responsabile solo del lavoro con i dati di un database) è anche l'invio di e-mail, il passaggio dall'API ad altri servizi, ecc.
  2. Inoltre, trovo inaccettabile inserire la logica aziendale in vista, perché in questo modo diventa difficile da controllare. Ad esempio, nella mia applicazione ci sono almeno tre modi per creare nuove istanze di Utente, ma tecnicamente dovrebbe crearle in modo uniforme.
  3. Non sempre mi accorgo quando i metodi e le proprietà dei miei modelli diventano non deterministiche e quando sviluppano effetti collaterali.

Ecco un semplice esempio. All'inizio, il modello User era così:

class User(db.Models): def get_present_name(self): return self.name o "Anonymous" def activate(self): self.status = "activated" self.save() 

Nel tempo, si è trasformato in questo:

class User(db .Models): def get_present_name(self): # la proprietà è diventata non deterministica in termini di database # i dati sono presi da un altro servizio da api return remote_api.request_user_name(self.uid) o "Anonymous" defactivate(self): # metodo ora ha un effetto collaterale (invia messaggio all'utente) self.status = "activated" self.save() send_mail("Il tuo account è attivato!", "‚Ķ", [self.email]) 

Quello che voglio è separare le entità nel mio codice:

  1. Entità del mio database, livello di persistenza: quali dati conserva la mia applicazione?
  2. Entità della mia applicazione, livello di logica aziendale: cosa fa la mia applicazione?

Quali sono le buone pratiche per implementare tale n approccio che può essere applicato in Django?