Hvad er modelarv i Django?

Modelarv er en Django ORM-funktion, der giver udviklere mulighed for at skabe hierarkiske relationer mellem databasemodeller. Det muliggør genbrug af kode, udvidelsesmuligheder og en renere kodebase ved at udnytte principperne for objektorienteret programmering.

Uanset om du bygger en kompleks webapplikation eller arbejder på et mindre projekt, kan modelarv tilbyde betydelige fordele, såsom at reducere redundans og sikre ensartet adfærd.

Typer af modelarv i Django

Django tilbyder understøttelse af tre typer modelarv:

1. Abstrakte basisklasser.
2. Multi-table arv.
3. Proxy modeller.

Hver af disse typer modelarv har fordele, og du vil bruge dem til specifikke formål.

Abstrakte basisklasser

Abstrakte basisklasser giver en måde at definere fælles felter og metoder, som flere modeller kan arve. For eksempel, hvis du har to modeller, der deler lignende felter, kan du bruge en abstrakt basisklasse til at definere de lignende felter. Tag et kig på dette eksempel:

klasseKunde(modeller. Model):
 navn = modeller. CharField (max_length=50)
 email = modeller. EmailField()
 kunde_id = modeller. IntegerField() 
klasseSælger(modeller. Model):
 navn = modeller. CharField (max_length=50)
 email = modeller. EmailField()
 sælger_id = modeller. IntegerField()

Kodestykket ovenfor definerer to Django-modeller: Kunde og Sælger. Disse modeller deler to fælles felter, nemlig navn og e-mail. For at forhindre denne redundans kan du oprette en separat model til at holde de fælles felter i Kunde og Sælger modeller og gør det abstrakt.

klasseBrugerinfo(modeller. Model):
 navn = modeller. CharField (max_length=50)
 email = modeller. EmailField()
klasseMeta:
 abstrakt = Rigtigt

Ovenstående kodestykke definerer en ny model og indstiller abstrakt tilskrive Rigtigt. Det betyder, at modellen vil være abstrakt, og Django vil ikke oprette en tabel i databasen.

Du kan omskrive Kunde og Sælger modeller som denne:

klasseKunde(Brugerinfo):
 kunde_id = modeller. IntegerField() 
klasseSælger(Brugerinfo):
 sælger_id = modeller. IntegerField()

I kodestykket ovenfor er Kunde og Sælgere modeller arver fra Brugerinfo model i stedet for modeller. Model.

Du kan se dine modeller i administratorpanelet ved at registrere dem i din admin.py fil som denne:

fra .modeller importere Kunde, Sælger
admin.site.register (kunde)
admin.site.register (sælger)

Migrer dine tilstande og start din udviklingsserver ved at køre følgende på en kommandolinje:

python manage.py makemigrationer \
 && python manage.py migrere \
 && python manage.py runserver

Naviger til dit adminwebsted og log ind med dine superbrugeroplysninger. Du bør se alle tre felter for hver model.

I dette eksempel har Django lavet en tabel til Kunde og Sælger modeller. Du kan se, at Brugerinfo modellen har ingen tabel, da den er abstrakt.

Multi-Table Arv

Du kan bruge multi-tabel nedarvning, når den overordnede model også skal eksistere som en tabel i databasen sammen med den underordnede model.

I modsætning til abstrakt basisklassearv, hvor den overordnede model ikke vil være en tabel i databasen, opretter multitabelarv en tabel for den overordnede model.

I multi-table nedarvning arver den underordnede model alle felter og metoder fra sin overordnede model og tilføjer sine specifikke felter. Fremmednøgler være med til at etablere modelforhold mellem forældre- og børnemodeller.

Her er et eksempel på multi-table arv:

klassePerson(modeller. Model):
 fornavn = modeller. CharField (max_length=100)
 efternavn = modeller. CharField (max_length=100)
deffå_navn(selv):
Vend tilbagef"{self.first_name}{self.last_name}"
klasseMeta:
 abstrakt = Rigtigt
klasseMedarbejder(Person):
 medarbejder_id = modeller. CharField (max_length=20)
 afdeling = modeller. CharField (max_length=100)
 løn = modeller. FloatField()
 dob = modeller. DateField()
klasseManager(medarbejder):
 titel = modeller. CharField (max_length=100)

Dette kodestykke definerer tre modeller. Den første model, kaldet Person, er abstrakt. Den definerer kun for- og efternavne på en person.

Den anden model, kaldet Medarbejder, arver felterne af Person men definerer yderligere felter. Det Medarbejder modellen er ikke abstrakt, så den vil have sin tabel i databasen.

Den endelige model, kaldet Manager, arver felterne af Medarbejder model og tilføjer et felt kaldet titel.

Forholdet mellem Medarbejder og Manager modeller kaldes Multi-Table Arv. Migrer dine modeller, registrer dem i admin.py, start din server, og naviger til administrationspanelet. Du bør se to tabeller oprettet af Django.

Når du forsøger at tilføje en ny administrator, vil du bemærke, at den har alle felterne fra Medarbejder model samt sit eget tilpassede felt.

Proxy modeller

En proxymodel hjælper dig med at oprette en ny model, der strækker sig fra en eksisterende model uden at oprette en ny databasetabel. I denne form for modelarv vil proxy- og originalmodellen dele den samme tabel. Ved at bruge proxy-modeller kan du gøre ting som at oprette brugerdefinerede modeller og ændre standardadministratorer.

Du kan oprette en proxy-model ved at tilføje proxy=Sand i Meta klasse. Her er et eksempel:

klasseProxyModel(BaseModel):
klasseMeta:
 proxy = Rigtigt

Typisk brug af en proxymodel er passende, når der eksisterer en basismodel, og der er behov for at skabe en specialiseret version af den med ekstra funktionalitet. Her er et grundlæggende eksempel:

klasseStolpe(modeller. Model):
 titel = modeller. CharField (max_length=30)
 forfatter = modeller. CharField (max_length=30)
def__str__(selv):
Vend tilbage selv.titel
klasseProxyPost(Stolpe):
klasseMeta:
 proxy = Rigtigt

Dette kodestykke definerer to modeller: Stolpe og MyPost. Det Stolpe model definerer to felter for titel og forfatter. Det ProxyPost model arver fra Stolpe model.

Migrer ovenstående modeller og tilføj et nyt indlæg til tabellen oprettet til Stolpe model.

Når du har tilføjet indlægget, skal du åbne Proxy indlæg bord. Du bør finde det indlæg, du føjede til Stolpe bord i den.

De ændringer, du foretager til indlæg i Proxy indlæg tabel vil påvirke det tilsvarende indlæg i Stolpe tabel og omvendt. Dette beviser, at de virkelig deler det samme bord.

Du kan ændre str() metode for proxy-modellen:

klasseProxyPost(Stolpe):
klasseMeta:
 proxy = Rigtigt
 bestilling = ["titel"]
def__str__(selv):
Vend tilbage selv.forfatter

Med denne ændring, a ProxyPosts strengrepræsentation vil være dens forfatter, ikke titlen. Rækkefølgen af ​​proxy-modellen vil også være efter titlen i stedet for standard ID-feltet.

Når du bruger proxy-modeller, skal du huske på, at du ikke kan tilføje brugerdefinerede felter til din proxy-model. Det primære brugstilfælde af proxy-modeller er, når du ønsker, at én model skal understøtte flere adfærd.

Proxymodeller hjælper dig med at ændre adfærden af ​​en eksisterende model uden at ændre dens felter eller den underliggende databasetabelstruktur.

Brug modelarv til genanvendelighed af kode og organisationsstruktur

Ved at bruge de forskellige teknikker til modelarv, kan du nemt oprette genbrugelig og organiseret kode til dit projekt.

Modelarv undgår overflødig kode og forbedrer vedligeholdelsen og skalerbarheden af ​​din kode. Det gør det også nemt at navigere i din kode og fremmer således et effektivt samarbejde mellem udviklingsteams.

Udover modelarv tilbyder Django skabelonarv, som er en fantastisk måde at administrere og organisere skabeloner til dine projekter på.