Ruby on Rails-applikasjonsflyt

mihailomilovanovic/Getty Images

01 av 07

Skinner applikasjonsflyt

Når du skriver dine egne programmer fra begynnelse til slutt, er det lett å se flytkontroll . Programmet starter her, det er en loop der, metodekall er her, alt er synlig. Men i en Rails-applikasjon er ikke ting så enkelt. Med et rammeverk av noe slag gir du fra deg kontroll over ting som 'flyt' til fordel for en raskere eller enklere måte å gjøre komplekse oppgaver på. Når det gjelder Ruby on Rails, håndteres flytkontrollen bak kulissene, og alt du sitter igjen med er (mer eller mindre) en samling av modeller, visning og kontrollere.

02 av 07

HTTP

Kjernen i enhver nettapplikasjon er HTTP. HTTP er nettverksprotokollen nettleseren din bruker for å snakke med en nettserver. Det er her begreper som 'forespørsel', 'GET' og 'POST' kommer fra, de er det grunnleggende vokabularet til denne protokollen. Men siden Rails er en abstraksjon av dette, vil vi ikke bruke mye tid på å snakke om det.

Når du åpner en nettside, klikker på en lenke eller sender inn et skjema i en nettleser, vil nettleseren koble seg til en webserver via TCP/IP. Nettleseren sender deretter serveren en 'forespørsel', tenk på det som et e-postskjema som nettleseren fyller ut og ber om informasjon på en bestemt side. Serveren sender til slutt nettleseren et 'svar'. Ruby on Rails er imidlertid ikke webserveren, webserveren kan være alt fra Webrick (det som vanligvis skjer når du starter en Rails-server fra kommandolinje ) til Apache HTTPD (nettserveren som driver det meste av nettet). Nettserveren er bare en tilrettelegger, den tar forespørselen og leverer den til Rails-applikasjonen din, som genererer responsen og sender den tilbake til serveren, som igjen sender den tilbake til klienten. Så flyten så langt er:

Klient -> Server -> [Rails] -> Server -> Klient

Men 'Rails' er det vi virkelig er interessert i, la oss grave dypere der.

03 av 07

Ruteren

Noe av det første en Rails-applikasjon gjør med en forespørsel, er å sende den gjennom ruteren. Hver forespørsel har en URL, dette er det som vises i adressefeltet til en nettleser. Ruteren er det som bestemmer hva som skal gjøres med den URL-en, om URL-en gir mening og om URL-en inneholder noen parametere. Ruteren er konfigurert i config/routes.rb .

Først må du vite at det endelige målet for ruteren er å matche en URL med en kontroller og handling (mer om disse senere). Og siden de fleste Rails-applikasjoner er RESTful, og ting i RESTful-applikasjoner er representert ved hjelp av ressurser, vil du se linjer som ressurser: innlegg i typiske Rails-applikasjoner. Dette samsvarer med nettadresser som /posts/7/edit med Posts-kontrolleren, den redigere handling på Posten med ID 7. Ruteren bestemmer bare hvor forespørslene går. Så blokken vår [Rails] kan utvides litt.

Ruter -> [Rails]

04 av 07

Kontrolløren

Nå som ruteren har bestemt hvilken kontroller den skal sende forespørselen til, og til hvilken handling på den kontrolleren, sender den den videre. En kontroller er en gruppe relaterte handlinger som alle er samlet i en klasse. For eksempel, i en blogg, er all koden for å vise, opprette, oppdatere og slette blogginnlegg samlet i en kontroller kalt 'Innlegg'. Handlingene er bare normale metoder av denne klassen. Kontrollere er plassert i app/kontrollere .

Så la oss si at nettleseren sendte en forespørsel om /innlegg/42 . Ruteren bestemmer at dette refererer til Post kontrolleren, den forestilling metoden og ID-en til innlegget som skal vises 42 , så det kaller forestilling metode med denne parameteren. De forestilling metoden er ikke ansvarlig for å bruke modellen til å hente dataene og bruke visningen til å lage utdataene. Så vår utvidede [Rails]-blokk er nå:

Ruter -> Kontroller#handling

05 av 07

Modellen

Modellen er både den enkleste å forstå og den vanskeligste å implementere. Modellen er ansvarlig for å samhandle med databasen. Den enkleste måten å forklare det på er modellen er et enkelt sett med metodekall som returnerer vanlige Ruby-objekter som håndterer alle interaksjoner (leser og skriver) fra databasen. Så etter bloggeksemplet vil API-en kontrolleren bruker for å hente data ved hjelp av modellen se omtrent slik ut Post.find(params[:id]) . De params er det ruteren analyserte fra URL-en, Post er modellen. Dette gjør SQL-spørringer, eller gjør det som trengs for å hente blogginnlegget. Modeller er plassert i app/modeller .

Det er viktig å merke seg at ikke alle handlinger trenger å bruke en modell. Samhandling med modellen er bare nødvendig når data må lastes fra databasen eller lagres i databasen. Som sådan setter vi et spørsmålstegn etter det i vårt lille flytskjema.

Ruter -> Kontroller#handling -> Modell?

06 av 07

Utsikten

Endelig er det på tide å begynne å generere litt HTML. HTML håndteres ikke av kontrolleren selv, og det håndteres heller ikke av modellen. Poenget med å bruke et MVC-rammeverk er å dele opp alt. Databaseoperasjoner forblir i modusen, HTML-generering forblir i visningen, og kontrolleren (kalles opp av ruteren) kaller dem begge.

HTML genereres vanligvis ved hjelp av innebygd Ruby. Hvis du er kjent med PHP, det vil si en HTML-fil med PHP-kode innebygd i den, vil embedded Ruby være veldig kjent. Disse utsiktene er plassert i app/visninger , og en kontroller vil kalle en av dem for å generere utdata og sende det tilbake til webserveren. Eventuelle data hentet av kontrolløren ved hjelp av modellen vil vanligvis bli lagret i en instansvariabel som, takket være litt Ruby-magi, vil være tilgjengelig som instansvariabler fra visningen. Embedded Ruby trenger heller ikke å generere HTML, den kan generere alle typer tekst. Du vil se dette når du genererer XML for RSS, JSON, etc.

Denne utgangen sendes tilbake til webserveren, som sender den tilbake til nettleseren, som fullfører prosessen.

07 av 07

Det komplette bildet

Og det er det, her er hele livet til en forespørsel til en Ruby on Rails-nettapplikasjon.

1. Nettleser – Nettleseren gjør forespørselen, vanligvis på vegne av brukeren når de klikker på en lenke.
2. Webserver - Webserveren tar forespørselen og sender den til Rails-applikasjonen.
3. Ruter - Ruteren, den første delen av Rails-applikasjonen som ser forespørselen, analyserer forespørselen og bestemmer hvilken kontroller/handlingspar den skal kalle.
4. Kontroller - Kontrolleren kalles. Kontrollørens jobb er å hente data ved hjelp av modellen og sende dem til en visning.
5. Modell - Hvis noen data må hentes, brukes modellen for å hente data fra databasen.
6. Vis - Dataene sendes til en visning, hvor HTML-utdata genereres.
7. Internett server - Den genererte HTML-en sendes tilbake til serveren, Rails er nå ferdig med forespørselen.
8. Nettleser - Serveren sender dataene tilbake til nettleseren, og resultatene vises.