Îmi place Django. Este un cadru bine gândit și intuitiv, cu un nume pe care îl pot pronunța cu voce tare. Îl puteți folosi pentru a învârti rapid un proiect de dimensiuni de weekend, și îl puteți folosi și pentru a rula aplicații complete de producție la scară.

Am făcut ambele lucruri și de-a lungul anilor am descoperit cum să folosesc unele dintre caracteristicile Django pentru o eficiență maximă. Acestea sunt:

  • Vizualizări bazate pe clasă versus funcții
  • Modele Django
  • Preluarea obiectelor cu interogări

Să vedem cum aceste instrumente vă permit să creați o aplicație performantă Django, plăcută de construit și de întreținut.

Vizualizări bazate pe clasă versus funcții

Amintiți-vă că Django este tot Python sub capotă. Când vine vorba de vizualizări, aveți două opțiuni: vizualizați funcțiile (uneori numite „vizualizări bazate pe funcții”) sau vederi bazate pe clase.

Cu ani în urmă, când am construit pentru prima dată ApplyByAPI, a fost inițial compus în întregime din vizualizări bazate pe funcții. Acestea oferă control granular și sunt bune pentru implementarea unei logici complexe. La fel ca într-o funcție Python, aveți un control complet (în bine sau în rău) asupra a ceea ce face vizualizarea.

Dar cu un control mare vine o mare responsabilitate, iar vizualizările bazate pe funcții pot fi puțin obositoare de utilizat. Sunteți responsabil pentru scrierea tuturor metodelor necesare pentru ca vizualizarea să funcționeze – aceasta vă permite să vă personalizați complet aplicația.

În cazul ApplyByAPI, au existat doar câteva locuri rare în care acel nivel de funcționalitate personalizată era cu adevărat necesar. Oriunde altundeva, punctele de vedere funcționale au început să-mi îngreuneze viața. Scrierea a ceea ce este, în esență, o vizualizare personalizată pentru operațiunile de execuție, precum afișarea datelor pe o pagină de listă, a devenit plictisitoare, repetitivă și predispusă la erori.

Cu vizualizările bazate pe funcții, veți avea nevoie să aflați ce metode Django să implementați pentru a gestiona cererile și a transmite datele vizualizărilor. Testarea unității poate necesita o muncă pentru a scrie. Pe scurt, controlul granular pe care îl oferă vizualizările bazate pe funcție necesită, de asemenea, niște plictiseală granulară pentru a fi implementat corect.

Am ajuns să opresc ApplyByAPI în timp ce am refactorizat majoritatea vizualizărilor în vizualizări bazate pe clase. Aceasta nu a fost o cantitate mică de muncă și refactorizare, dar când s-a terminat, am avut o grămadă de vederi minuscule care au făcut o diferență uriașă. Adică, uită-te la acesta:

class ApplicationsList(ListView):
    model = Application
    template_name = "applications.html"

Sunt trei rânduri. Ergonomia dezvoltatorului meu și viața mea au devenit mult mai ușoare.

S-ar putea să vă gândiți la vizualizările bazate pe clase ca la șabloane care acoperă majoritatea funcționalităților de care are nevoie orice aplicație. Există vizualizări pentru afișarea listelor de lucruri, pentru vizualizarea unui lucru în detaliu și editarea vizualizărilor pentru efectuarea operațiilor CRUD (Creare, Citire, Actualizare, Ștergere).

Deoarece implementarea uneia dintre aceste vederi generice necesită doar câteva linii de cod, logica aplicației mele a devenit dramatic succintă. Acest lucru mi-a oferit un cod mai puțin repetat, mai puține locuri pentru ca ceva să meargă prost și o aplicație mai ușor de gestionat în general.

Vizualizările bazate pe clasă sunt rapid de implementat și utilizat. Vizualizările generice bazate pe clasă pot necesita mai puțină muncă pentru a testa, deoarece nu este nevoie să scrieți teste pentru vizualizarea de bază pe care Django o oferă. (Django își face propriile teste în acest sens; nu este nevoie ca aplicația dvs. să verifice de două ori.)

Pentru a adapta o viziune generică la nevoile dvs., puteți subclasă o vedere generică și suprascrie atributele sau metodele. În cazul meu, deoarece nu aveam nevoie decât să scriu teste pentru orice personalizări pe care le-am adăugat, fișierele mele de testare au devenit dramatic mai scurte, la fel ca și timpul și resursele necesare pentru a le rula.

Când cântăriți alegerea dintre vizualizările bazate pe funcții sau pe clase, luați în considerare cantitatea de personalizare de care are nevoie vizualizarea și munca viitoare care va fi necesară pentru testarea și întreținerea acesteia.

Dacă logica este comună, este posibil să puteți lovi terenul cu o vizualizare generică bazată pe clase. Dacă aveți nevoie de o granularitate suficientă pentru ca rescrierea metodelor unei vizualizări de bază să o facă prea complicată, luați în considerare o vizualizare bazată pe funcții.

Modele Django

Modele organizați conceptele centrale ale aplicației dvs. Django pentru a le face flexibile, robuste și ușor de utilizat. Dacă sunt folosite cu înțelepciune, modelele reprezintă un mod puternic de a strânge datele într-o sursă definitivă de adevăr.

La fel ca vizualizările, Django oferă câteva tipuri de modele încorporate pentru comoditatea implementării autentificării de bază, inclusiv Utilizator și Permisiune modele. Pentru orice altceva, puteți crea un model care să vă reflecte conceptul moștenirea de la o clasă Model părinte.

class StaffMember(models.Model):
    user = models.OneToOneField(User, on_delete=models.CASCADE)
    company = models.OneToOneField(Company, on_delete=models.CASCADE)

    def __str__(self):
        return self.company.name + " - " + self.user.email

Când creați un model personalizat în Django, faceți subclasă Clasa modelului lui Django și profită de toată puterea sa. Fiecare model pe care îl creați mapează, în general, un tabel de baze de date. Fiecare atribut este un câmp de bază de date. Acest lucru vă oferă posibilitatea de a crea obiecte pentru a lucra cu care oamenii pot înțelege mai bine.

Puteți face un model util pentru dvs. definind câmpurile sale. Mulți tipuri de câmp încorporate sunt furnizate convenabil. Acestea ajută Django să descopere tipul de date, HTML widget de utilizat la redarea unui formular și chiar validarea formularului cerințe. Dacă aveți nevoie, puteți scrie câmpuri model personalizate.

Bază de date relații poate fi definit folosind un Cheie externă câmp (multi-la-unu), sau a ManyToManyField (îți dau trei presupuneri). Dacă acestea nu sunt suficiente, există și un OneToOneField.

Împreună, acestea vă permit să definiți relații între modelele dvs. cu niveluri de complexitate limitate doar de imaginația dvs. (În funcție de imaginația pe care o aveți, acest lucru poate fi sau nu un avantaj.)

Preluarea obiectelor cu interogări

Utilizați Managerul modelului dvs. (objects implicit) la construiți un QuerySet. Aceasta este o reprezentare a obiectelor din baza de date pe care le puteți rafina, folosind metode, pentru a recupera subseturi specifice. Toate metodele disponibile sunt în API QuerySet și pot fi înlănțuite împreună pentru a vă distra și mai mult.

Post.objects.filter(
    type="new"
).exclude(
    title__startswith="Blockchain"
)

Unele metode returnează QuerySets noi, cum ar fi filter(), sau exclude(). Înlănțuirea acestora vă poate oferi interogări puternice fără a afecta performanța, deoarece QuerySets nu sunt preluate din baza de date până când sunt evaluate. Metodele care evaluează un QuerySet includ get(), count(), len(), list(), sau bool().

Iterarea peste un QuerySet îl evaluează, de aceea evitați să faceți acest lucru acolo unde este posibil pentru a îmbunătăți performanța interogării. De exemplu, dacă doriți doar să știți dacă este prezent un obiect, puteți utiliza exists() pentru a evita iterarea asupra obiectelor bazei de date.

Utilizare get() în cazurile în care doriți să recuperați un anumit obiect. Această metodă crește MultipleObjectsReturned dacă se întâmplă ceva neașteptat, precum și DoesNotExist excepție, dacă, presupuneți.

Dacă doriți să obțineți un obiect care poate să nu existe în contextul cererii unui utilizator, utilizați opțiunea convenabilă get_object_or_404() sau get_list_or_404() care ridică Http404 în loc de DoesNotExist. Acestea sunt utile comenzi rapide sunt potrivite doar pentru acest scop. Pentru a crea un obiect care nu există, există și convenabilul get_or_create().

Elementele esențiale eficiente

Aveți acum un control asupra acestor trei instrumente esențiale pentru construirea aplicației Django eficiente – felicitări!

Există mai multe lucruri pe care Django le poate face pentru dvs., așa că stați la curent cu articolele viitoare.

Dacă aveți de gând să construiți pe GitHub, s-ar putea să vă placă să-l configurați django-security-check GitHub Action. Între timp, sunteți pe cale să construiți un proiect software frumos.