Forstå det grundlæggende i Ruby on Rails: HTTP, MVC og Routes

Efter at have lært dit første programmeringssprog kan du måske spørge hvad du kan gøre med programmering: AI / Machine Learning? Hardwareudvikling? Mobile apps? Eller måske vil du begynde at udvikle webapplikationer! :)

Her forstår vi det grundlæggende i, hvordan internettet, ruterne og MVC-arkitekturen fungerer ved hjælp af Ruby on Rails-webrammen. Lad os dykke ned i webverdenen.

Før jeg lærer webudvikling med Rails, anbefaler jeg virkelig at lære om Ruby først .

Hvordan fungerer internettet?

Internettet har en masse lag (Application, TCP, Internet, Hardware lag), som alle er forbundet. Men dybest set fungerer det gennem HTTP ( Hypertext Transfer Protocol ).

Den Hypertext Transfer Protocol ( HTTP ) er et program protokol for distribueret, kollaborative, hypermedier informationssystemer. - Wikipedia

Den HTTP fungerer som en anmodning - svar cyklus i klient - server -model.

Vi har en webbrowser (f.eks. Google Chrome). Så vi skriver www.google.comURL'en, og klienten sender HTTP- anmodningen (anmodningsmeddelelse) til serveren . Den server returnerer HTTP-svar (svar budskab - i så fald svaret er HTML fra Googles hjemmeside).

Den klient gør anmodningen og modtager svar fra serveren . Klienten håndterer brugergrænsefladen og brugerinteraktioner. På serveren kan vi gemme og hente data (på databaser), behandle logik i baggrunden (medarbejdere / job) og mange andre ting.

Hvis du vil forstå det dybt, foreslår jeg nogle ressourcer. Jeg er en stor fan af Preethis indlæg. Her en serie på 3 dele :

  • En primer for nybegyndere til webudvikling
  • Client-Server Model & Structure of a Web Application
  • HTTP & REST

MVC-arkitekturen og skinneruterne

Nu hvor vi forstår, hvordan Internettet fungerer, studerer vi MVC-arkitekturen og Rails Routes.

MVC står for Model, View og Controller.

På denne arkitektur har vi " adskillelsen af ​​bekymringerne " mellem modeller, synspunkter og controllere. Hver del har sit eget ansvar. Lad os dykke ned i hver del.

Model

“Vedligeholder forholdet mellem objekt og database og håndterer validering, tilknytning, transaktioner”

Dette betyder, at modellen vil opretholde et ekstremt forhold til databasen . Hver model (kan) repræsenterer en databasetabel (i tilfælde af SQL-databaser). Dette modelobjekt får muligheder (arvet fra ActiveRecord - Rails-klasse) til at hente, gemme, redigere og slette data fra databasetabellen. Vi bruger modelobjekter som et lag mellem vores applikation og databasen.

Udover dette forhold til databasen kan modellen skabe valideringer og associering mellem modeller.

Udsigt

"En præsentation af data i et bestemt format, udløst af en controllerens beslutning om at præsentere dataene."

Dette er præsentationen af ​​anmodningens svar . Denne præsentation kan være i en række formattyper: PDF, HTML, JSON osv. Det endelige resultat af en visning vil sandsynligvis være brugergrænsefladen (UI) - en del af "klienten".

For de fleste sider på internettet vil visningerne være en HTML-stil med CSS og JS. Men vi kan implementere PDF-filer af brugeradfærd på et Travel digitalt produkt for at vise alle medarbejdere, hvordan folk også bruger deres hjemmeside.

Controller

"Anlægget i applikationen, der dirigerer trafik, på den ene side forespørgsel til modellerne for specifikke data og på den anden side organisere disse data (søgning, sortering) i en form, der passer til behovene i en given visning."

Controlleren er "Maestro." Det tager sig af strømmen: bruger modeller til at foretage forespørgsler, parser data og træffe beslutninger om, i hvilket format du vil præsentere dataene.

MVC & Routes cykler på et Rails-program

Så forestil dig, at vi arbejder i en Travel Startup. En del af produktet er at præsentere en liste over gode artikler om rejsehistorier og tip til rejsende.

Tænk bare fra den rejsendes perspektiv. Du går til, www.worldpackers.com/articlesog du ser en smuk side, der indeholder en masse gode artikler.

Når du skriver denne URL i browseren, fremsætter den en anmodning til serveren. På serveren har vi Rails webapplikationen. Rails Router verificerer, om der er en post, der matcher den anmodede URL.

Vi skal bare konfigurere ruterne til denne linje:

Dette vil skabe RESTful ruter til artikler. Hvis vi løber bundle exec rake routes, viser den listen over oprettede stier.

HTTP verbum kan være GET, POST, PATCH, PUT, eller DELETE. Og vi ved, hvordan Rails kortlægger hver PATHtil højre controllerog action. Læs mere her.

I vores tilfælde modtager serveren /articlessti og GETsom HTTP-verbet. Det kortlægges til ArticlesControllerog indexhandling.

I controllerenArticlesController bruger vi modellenArticle til at få alle artikler i databasen og gengive visningenindex.html.erb som serverrespons (UI).

Efter konvention gengiver denne controller visningen i views/articles/index.html.erb. Dybest set er det en almindelig HTML-fil, der drives af Ruby.

Rails anmodnings-svar cyklus er et af de første begreber, du har brug for at forstå, når du begynder at lære webudvikling.

Brugeren laver ting (anmodning til serveren), Rails-applikationen har routeren til at kortlægge URL-stien til den rigtige controller. I controlleren kan vi gøre alle ting med en model (eller mere end en model) - hvilket betyder at få, gemme, redigere, slette data - og gengive en visning til brugeren.

Det er alt!

Vi lærte meget her. Jeg håber, at I sætter pris på indholdet og lærer mere om, hvordan MVC-arkitekturen og routingen fungerer på Rails.

Dette er endnu et skridt fremad på min rejse til at lære og mestre Rails og webudvikling. Du kan se dokumentationen for min komplette rejse her på min Renaissance Developer-publikation .

Hvis du vil have et komplet Ruby and Rails-kursus, lære rigtige kodningsfærdigheder og opbygge projekter, prøv One Month Ruby Bootcampog Rails Bootcamp . Vi ses der ☺

Hav det sjovt, og bliv ved med at lære og kode.

Min Twitter & Github. ☺