Ruby on Rails taotlusvoog

Kui kirjutate algusest lõpuni oma programme, on seda lihtne näha voolu juhtimine. Programm algab siit, seal on silmus, meetodikõned on kohal, see on kõik nähtav. Kuid Rails-rakenduses pole asjad nii lihtsad. Mis tahes raamistiku korral loobute juhtimisest selliste asjade üle nagu "voog" kiiremate või lihtsamate viiside kasuks keerukate ülesannete täitmiseks. Ruby on Rails puhul käsitletakse voo juhtimist kõik kulisside taga ja kõik, mis teile silma jääb, on (enam-vähem) mudelite, vaadete ja kontrollerite kollektsioon.

Mis tahes veebirakenduse keskmes on HTTP. HTTP on võrguprotokoll, mida teie veebibrauser kasutab veebiserveriga rääkimiseks. Siit pärinevad sellised mõisted nagu "taotlus", "GET" ja "POST", mis on selle protokolli põhisõnavara. Kuna Rails on siiski selle abstraktsioon, ei kuluta me sellele rääkimiseks palju aega.

Veebilehe avamisel klõpsake lingil või esitage veebibrauseris vorm, brauser loob veebiserveriga ühenduse TCP / IP kaudu. Seejärel saadab brauser serverile päringu, mõelge sellele nagu e-posti vormis, mille brauser täidab teatud lehelt teabe küsimisega. Lõpuks saadab server veebibrauserile "vastuse". Ruby on Rails pole siiski veebiserver, veebiserveriks võib olla ükskõik milline Webrick (mis juhtub tavaliselt siis, kui käivitate Rails serveri alates

instagram viewer
käsurida) Apache HTTPD-le (veebiserver, mis töötab suurema osa veebist). Veebiserver on vaid hõlbustaja, ta võtab taotluse vastu ja annab selle teie Rails rakendusele, mis genereerib vastuse ja edastab, saadetakse tagasi serverile, kes omakorda saadab selle tagasi serverile klient. Senine voog on:

Üks esimesi asju, mida Rails-rakendus taotlusega teeb, on saata see ruuteri kaudu. Igal taotlusel on URL, see kuvatakse veebibrauseri aadressiribal. Kui URL on mõttekas ja kui URL sisaldab mingeid parameetreid, määrab selle ruuteri see, mida selle URL-iga teha tuleb. Ruuter on konfigureeritud sisse konfiguratsioon / marsruudid.rb.

Esiteks teadke, et ruuteri lõppeesmärk on sobitada URL kontrolleri ja toiminguga (nende kohta lisateave hiljem). Ja kuna enamus Rails'i rakendusi on RESTful ja RESTful rakendustes on ressursse esindatud, näete ridu nagu ressursid: postitused tüüpilistes Rails'i rakendustes. See sobib URL-idega nagu /posts/7/edit koos postituste kontrolleriga redigeeri tegevus postituses ID-ga 7. Ruuter otsustab lihtsalt, kuhu taotlused lähevad. Nii et meie [Rails] plokki saab natuke laiendada.

Nüüd, kui ruuter on otsustanud, millisele kontrollerile päring saata ja millisele sellele kontrollerile toiminguga tegeleb, saadab ta selle edasi. Kontroller on seotud toimingute rühm, mis kõik on klassis kokku pandud. Näiteks ajaveebis on kogu blogi postituste kuvamiseks, loomiseks, värskendamiseks ja kustutamiseks kogu kood ühendatud kontrolleriga, mille nimi on „Postitamine”. Toimingud on lihtsalt tavalised meetodid sellest klassist. Kontrollerid asuvad rakendus / kontrollerid.

Ütleme nii, et veebibrauser saatis taotluse /posts/42. Ruuter otsustab, see viitab Postita kontroller, show meetod ja kuvatava postituse ID on 42, nii et see kutsub show meetod selle parameetriga. show meetod ei vastuta mudeli kasutamise eest andmete hankimiseks ja vaate kasutamise eest väljundi loomiseks. Nii et meie laiendatud [Rails] plokk on nüüd:

Mudel on nii kõige lihtsamini mõistetav kui ka kõige keerulisem rakendatav. Mudel vastutab andmebaasiga suhtlemise eest. Lihtsaim viis mudeli selgitamiseks on lihtne meetodikõnede komplekt, mis tagastab tavalised rubiinobjektid, mis käsitlevad andmebaasis kõiki interaktsioone (loeb ja kirjutab). Nii et ajaveebi näite järgi näeb API, mida kontroller kasutab mudeli abil andmete saamiseks, umbes selline Post.find (parameetrid [: id]). parameetrid mida ruuter URL-ist sõelub, on mudel Post. See teeb SQL-i päringuid või teeb kõik, mida on vaja ajaveebi postituse toomiseks. Mudelid asuvad rakendus / mudelid.

Oluline on märkida, et mitte kõik toimingud ei pea kasutama mudelit. Mudeliga suhtlemine on vajalik ainult siis, kui andmed tuleb andmebaasist laadida või andmebaasi salvestada. Sellena paneme pärast seda meie väikesesse vooskeemi küsimärgi.

Lõpuks on aeg hakata genereerima mõnda HTML-i. HTML-i ei käsitle vastutav töötleja ise ega mudel. MVC raamistiku kasutamise mõte on jagada kõik osadeks. Andmebaasi toimingud püsivad režiimis, HTML-generatsioon jääb vaatesse ja kontroller (ruuteri kutsutud) kutsub neid mõlemaid.

HTML genereeritakse tavaliselt manustatud Ruby abil. Kui olete PHP-ga tuttav, see tähendab HTML-fail, millele on manustatud PHP-kood, siis on manustatud Ruby väga tuttav. Need vaated asuvad rakendus / vaatedja kontroller helistab ühele neist väljundi genereerimiseks ja saadab selle veebiserverisse tagasi. Kõik mudeli abil vastutava töötleja poolt kogutud andmed salvestatakse üldjuhul andmebaasi esinemismuutuja mis tänu mõnele rubiinmaagiale on vaatest seestpoolt saadaval muutujatena. Manustatud Ruby ei pea HTML-i genereerima, see võib genereerida mis tahes tüüpi teksti. Näete seda, kui genereerite XML-i RSS, JSON jne jaoks.

See väljund saadetakse tagasi veebiserverisse, mis saadab selle tagasi veebibrauserisse, mis protsessi lõpule viib.