Hva er modellarv i Django?

Modellarv er en Django ORM-funksjon som lar utviklere lage hierarkiske relasjoner mellom databasemodeller. Det muliggjør gjenbruk av kode, utvidbarhet og en renere kodebase ved å utnytte prinsippene for objektorientert programmering.

Enten du bygger en kompleks nettapplikasjon eller jobber med et mindre prosjekt, kan modellarv tilby betydelige fordeler, som å redusere redundans og sikre konsistent oppførsel.

Typer modellarv i Django

Django tilbyr støtte for tre typer modellarv:

1. Abstrakte grunnklasser.
2. Flerbordsarv.
3. Proxy-modeller.

Hver av disse typene modellarv har fordeler, og du vil bruke dem til spesifikke formål.

Abstrakte grunnklasser

Abstrakte basisklasser gir en måte å definere vanlige felt og metoder som flere modeller kan arve. Hvis du for eksempel har to modeller som deler lignende felt, kan du bruke en abstrakt basisklasse for å definere de lignende feltene. Ta en titt på dette eksemplet:

klasseKunde(modeller. Modell):
 navn = modeller. CharField (max_length=50)
 e-post = modeller. EmailField()
 kunde_id = modeller. IntegerField() 
klasseSelger(modeller. Modell):
 navn = modeller. CharField (max_length=50)
 e-post = modeller. EmailField()
 selger_id = modeller. IntegerField()

Kodebiten ovenfor definerer to Django-modeller: Kunde og Selger. Disse modellene deler to felles felt, nemlig Navn og e-post. For å forhindre denne redundansen, kan du opprette en egen modell for å holde de vanlige feltene i Kunde og Selger modeller og gjøre det abstrakt.

klasseBrukerinformasjon(modeller. Modell):
 navn = modeller. CharField (max_length=50)
 e-post = modeller. EmailField()
klasseMeta:
 abstrakt = ekte

Kodebiten ovenfor definerer en ny modell og setter abstrakt tilskrive ekte. Dette betyr at modellen vil være abstrakt, og Django vil ikke lage en tabell i databasen.

Du kan skrive om Kunde og Selger modeller som dette:

klasseKunde(Brukerinformasjon):
 kunde_id = modeller. IntegerField() 
klasseSelger(Brukerinformasjon):
 selger_id = modeller. IntegerField()

I kodebiten ovenfor er Kunde og Selgere modeller arver fra Brukerinformasjon modell i stedet for modeller. Modell.

Du kan se modellene dine i administrasjonspanelet ved å registrere dem i din admin.py fil slik:

fra .modeller import Kunde, Selger
admin.site.register (kunde)
admin.site.register (selger)

Migrer modusene dine og start utviklingsserveren ved å kjøre følgende på en kommandolinje:

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

Naviger til administrasjonssiden din og logg på med superbrukeropplysningene dine. Du bør se alle tre feltene for hver modell.

I dette eksemplet har Django laget en tabell for Kunde og Selger modeller. Du kan se at Brukerinformasjon Modellen har ingen tabell siden den er abstrakt.

Multi-Table Arv

Du kan bruke flertabellsarv når den overordnede modellen også må eksistere som en tabell i databasen ved siden av den underordnede modellen.

I motsetning til abstrakt basisklassearv, der den overordnede modellen ikke vil være en tabell i databasen, oppretter flertabellsarv en tabell for den overordnede modellen.

I multi-tabell arv arver den underordnede modellen alle feltene og metodene fra den overordnede modellen og legger til de spesifikke feltene. Fremmednøkler bidra til å etablere modellforhold mellom foreldre- og barnemodeller.

Her er et eksempel på flerbordsarv:

klassePerson(modeller. Modell):
 fornavn = modeller. CharField (max_length=100)
 etternavn = modeller. CharField (max_length=100)
defget_name(selv):
komme tilbakef"{self.first_name}{self.last_name}"
klasseMeta:
 abstrakt = ekte
klasseAnsatt(Person):
 ansatt_id = modeller. CharField (max_length=20)
 avdeling = modeller. CharField (max_length=100)
 lønn = modeller. FloatField()
 dob = modeller. DateField()
klassesjef(Ansatt):
 tittel = modeller. CharField (max_length=100)

Denne kodebiten definerer tre modeller. Den første modellen, kalt Person, er abstrakt. Den definerer bare for- og etternavnet til en person.

Den andre modellen, kalt Ansatt, arver feltene til Person men definerer tilleggsfelt. De Ansatt modellen er ikke abstrakt, så den vil ha sin tabell i databasen.

Den endelige modellen, kalt sjef, arver feltene til Ansatt modell og legger til et felt kalt tittel.

Forholdet mellom Ansatt og sjef modeller kalles Multi-Table Arv. Migrer modellene dine, registrer dem inn admin.py, start serveren din og naviger til administrasjonspanelet. Du bør se to tabeller laget av Django.

Når du prøver å legge til en ny leder, vil du legge merke til at den har alle feltene fra Ansatt modell samt eget tilpasset felt.

Proxy-modeller

En proxy-modell hjelper deg med å lage en ny modell som strekker seg fra en eksisterende modell uten å opprette en ny databasetabell. I denne typen modellarv vil proxy- og originalmodellene dele samme tabell. Ved å bruke proxy-modeller kan du gjøre ting som å lage tilpassede modeller og endre standardadministratorer.

Du kan opprette en proxy-modell ved å legge til proxy=Sant i Meta klasse. Her er et eksempel:

klasseProxyModel(BaseModel):
klasseMeta:
 proxy = ekte

Typisk bruk av en proxy-modell er hensiktsmessig når en basismodell eksisterer og det er behov for å lage en spesialisert versjon av den med ekstra funksjonalitet. Her er et grunnleggende eksempel:

klassePost(modeller. Modell):
 tittel = modeller. CharField (max_length=30)
 forfatter = modeller. CharField (max_length=30)
def__str__(selv):
komme tilbake selvtittel
klasseProxyPost(Post):
klasseMeta:
 proxy = ekte

Denne kodebiten definerer to modeller: Post og MyPost. De Post modellen definerer to felt for tittel og forfatter. De ProxyPost modellen arver fra Post modell.

Migrer modellene ovenfor og legg til et nytt innlegg i tabellen opprettet for Post modell.

Etter å ha lagt til innlegget, åpne Proxy-innlegg bord. Du bør finne innlegget du la til Post bord i den.

Endringene du gjør i innlegg i Proxy-innlegg tabellen vil påvirke det tilsvarende innlegget i Post tabell og omvendt. Dette beviser at de virkelig deler samme bord.

Du kan endre str() metode for proxy-modellen:

klasseProxyPost(Post):
klasseMeta:
 proxy = ekte
 bestilling = ["tittel"]
def__str__(selv):
komme tilbake selv.forfatter

Med denne modifikasjonen, a ProxyPost sine strengrepresentasjon vil være forfatteren, ikke tittelen. Rekkefølgen av proxy-modellen vil også skje etter tittelen i stedet for standard ID-feltet.

Når du bruker proxy-modeller, bør du huske på at du ikke kan legge til egendefinerte felt i proxy-modellen. Den primære bruken av proxy-modeller er når du vil at én modell skal støtte flere atferd.

Proxy-modeller hjelper deg med å endre oppførselen til en eksisterende modell uten å endre feltene eller den underliggende databasetabellstrukturen.

Bruk modellarv for gjenbruk av kode og organisasjonsstruktur

Ved å bruke de forskjellige teknikkene for modellarv, kan du enkelt lage gjenbrukbar og organisert kode for prosjektet ditt.

Modellarv unngår overflødig kode og forbedrer vedlikeholdbarheten og skalerbarheten til koden din. Det gjør det også enkelt å navigere i koden din, og fremmer dermed effektivt samarbeid mellom utviklingsteam.

Bortsett fra modellarv, tilbyr Django malarv, som er en fin måte å administrere og organisere maler for prosjektene dine på.