Rozdzielenie logiki biznesowej i dostępu do danych w django

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

Piszę projekt w Django i widzę, że 80% kodu znajduje się w pliku models.py. Ten kod jest mylący i po pewnym czasie przestaję rozumieć, co się naprawdę dzieje.

Oto, co mnie niepokoi:

  1. Uważam za brzydkie, że mój model poziomie (który miał odpowiadać tylko za pracę z danymi z bazy danych) to także wysyłanie e-maili, chodzenie po API do innych usług itp.
  2. Ponadto uważam za niedopuszczalne umieszczanie logiki biznesowej w widok, ponieważ w ten sposób trudno jest go kontrolować. Na przykład w mojej aplikacji istnieją co najmniej trzy sposoby tworzenia nowych instancji User, ale technicznie powinno to tworzyć je jednolicie.
  3. Nie zawsze zauważam, kiedy metody i właściwości moich modeli stają się niedeterministyczne i kiedy wywołują skutki uboczne.

Oto prosty przykład. Początkowo model User wyglądał tak:

class User(db.Models): def get_present_name(self): return self.name lub "Anonymous" def Activate(self): self.status = "aktywowane" self.save() 

Z biegiem czasu zmieniło się to w to:

class User(db .Models): def get_present_name(self): # właściwość stała się niedeterministyczna pod względem bazy danych # dane są pobierane z innej usługi przez api return remote_api.request_user_name(self.uid) lub "Anonimowy" def Activate(self): # metoda teraz ma efekt uboczny (wyślij wiadomość do użytkownika) self.status = "aktywowane" self.save() send_mail("Twoje konto jest aktywowane!", "‚ʶ", [self.email]) 

Chcę oddzielić encje w moim kodzie:

  1. Eencje mojej bazy danych, poziom trwałości: Jakie dane przechowuje moja aplikacja?
  2. Jednostki mojej aplikacji, poziom logiki biznesowej: co robi moja aplikacja?

Jakie są dobre praktyki wdrażania takich n podejście, które można zastosować w Django?