Ruby on Rails-toepassingsstroom

mihailomilovanovic/Getty Images

01 van 07

Rails-toepassingsstroom

Als je van begin tot eind je eigen programma's schrijft, is dat gemakkelijk te zien stroomregeling . Het programma start hier, er is een lus daar, methodeaanroepen zijn hier, het is allemaal zichtbaar. Maar in een Rails-toepassing is het niet zo eenvoudig. Met een raamwerk van welke aard dan ook, geef je de controle over zaken als 'flow' uit handen ten gunste van een snellere of eenvoudigere manier om complexe taken uit te voeren. In het geval van Ruby on Rails wordt de flow control allemaal achter de schermen afgehandeld, en alles wat je overhoudt is (min of meer) een verzameling modellen, weergaven en controllers.

02 van 07

HTTP

De kern van elke webapplicatie is HTTP. HTTP is het netwerkprotocol dat uw webbrowser gebruikt om met een webserver te praten. Dit is waar termen als 'verzoek', 'GET' en 'POST' vandaan komen, ze vormen de basiswoordenschat van dit protocol. Omdat Rails hier echter een abstractie van is, zullen we er niet veel tijd aan besteden.

Wanneer u een webpagina opent, op een link klikt of een formulier verzendt in een webbrowser, maakt de browser verbinding met een webserver via TCP/IP. De browser stuurt de server vervolgens een 'verzoek', zie het als een mail-in-formulier dat de browser invult om informatie op een bepaalde pagina op te vragen. De server stuurt de webbrowser uiteindelijk een 'reactie'. Ruby on Rails is echter niet de webserver, de webserver kan van alles zijn van Webrick (wat meestal gebeurt als je een Rails-server start vanaf de opdrachtregel ) naar Apache HTTPD (de webserver die het grootste deel van het web aandrijft). De webserver is slechts een facilitator, hij neemt het verzoek en geeft het door aan uw Rails-toepassing, die het antwoord genereert en doorgeeft aan de server, die het op zijn beurt terugstuurt naar de client. Dus de stroom tot nu toe is:

Client -> Server -> [Rails] -> Server -> Client

Maar 'Rails' is waar we echt in geïnteresseerd zijn, laten we daar dieper op ingaan.

03 van 07

De router

Een van de eerste dingen die een Rails-toepassing doet met een verzoek, is om het door de router te sturen. Elk verzoek heeft een URL, dit is wat er in de adresbalk van een webbrowser verschijnt. De router bepaalt wat er met die URL moet gebeuren, of de URL zinvol is en of de URL parameters bevat. De router is geconfigureerd in config/routes.rb .

Weet eerst dat het uiteindelijke doel van de router is om een ​​URL te matchen met een controller en actie (hierover later meer). En aangezien de meeste Rails-applicaties RESTful zijn en dingen in RESTful-applicaties worden weergegeven met bronnen, zie je regels als bronnen :berichten in typische Rails-toepassingen. Dit komt overeen met URL's zoals /posts/7/edit met de Posts-controller, de Bewerk actie op de Post met de ID van 7. De router bepaalt gewoon waar verzoeken naartoe gaan. Dus ons [Rails]-blok kan wat worden uitgebreid.

Router -> [Rails]

04 van 07

De controller

Nu de router heeft besloten naar welke controller het verzoek moet worden verzonden en naar welke actie op die controller, wordt het doorgestuurd. Een controller is een groep gerelateerde acties die allemaal in een klasse zijn gebundeld. In een blog is bijvoorbeeld alle code voor het bekijken, maken, bijwerken en verwijderen van blogberichten gebundeld in een controller genaamd 'Post'. De acties zijn gewoon normaal methoden van deze klasse. Controllers bevinden zich in app/controllers .

Dus laten we zeggen dat de webbrowser een verzoek heeft verzonden om: /posts/42 . De router besluit dat dit verwijst naar de Na controleur, de show methode en de ID van het te tonen bericht is 42 , dus het noemt de show methode met deze parameter. De show methode is niet verantwoordelijk voor het gebruik van het model om de gegevens op te halen en voor het gebruik van de weergave om de uitvoer te maken. Dus ons uitgebreide [Rails]-blok is nu:

Router -> Controller#actie

05 van 07

Het model

Het model is zowel het eenvoudigst te begrijpen als het moeilijkst te implementeren. Het model is verantwoordelijk voor de interactie met de database. De eenvoudigste manier om het uit te leggen, is dat het model een eenvoudige set methodeaanroepen is die gewone Ruby-objecten retourneren die alle interacties (lezen en schrijven) uit de database afhandelen. Dus volgens het blogvoorbeeld ziet de API die de controller zal gebruiken om gegevens op te halen met behulp van het model er ongeveer zo uit: Post.find(params[:id]) . De params is wat de router uit de URL heeft geparseerd, Post is het model. Dit maakt SQL-query's of doet wat nodig is om de blogpost op te halen. Modellen bevinden zich in app/modellen .

Het is belangrijk op te merken dat niet alle acties een model hoeven te gebruiken. Interactie met het model is alleen vereist wanneer gegevens uit de database moeten worden geladen of in de database moeten worden opgeslagen. Daarom plaatsen we er een vraagteken achter in ons kleine stroomdiagram.

Router -> Controller#action -> Model?

06 van 07

Het uitzicht

Eindelijk is het tijd om wat HTML te genereren. HTML wordt niet afgehandeld door de controller zelf en ook niet door het model. Het punt van het gebruik van een MVC-framework is om alles te compartimenteren. Databasebewerkingen blijven in de modus, HTML-generatie blijft in het zicht en de controller (aangeroepen door de router) roept ze allebei op.

HTML wordt normaal gesproken gegenereerd met behulp van embedded Ruby. Als je bekend bent met PHP, dat wil zeggen een HTML-bestand met daarin ingesloten PHP-code, dan zal ingebedde Ruby heel bekend zijn. Deze weergaven bevinden zich in app/weergaven , en een controller zal een van hen aanroepen om de uitvoer te genereren en terug te sturen naar de webserver. Alle gegevens die door de verwerkingsverantwoordelijke worden opgehaald met behulp van het model, worden over het algemeen opgeslagen in een instantie variabele die, dankzij wat Ruby-magie, beschikbaar zal zijn als instantievariabelen vanuit de weergave. Ook hoeft ingebedde Ruby geen HTML te genereren, het kan elk type tekst genereren. U ziet dit bij het genereren van XML voor RSS, JSON, enz.

Deze uitvoer wordt teruggestuurd naar de webserver, die deze terugstuurt naar de webbrowser, die het proces voltooit.

07 van 07

Het complete plaatje

En dat is het, hier is het volledige leven van een verzoek aan een Ruby on Rails-webtoepassing.

1. Webbrowser - De browser doet het verzoek, meestal namens de gebruiker wanneer deze op een link klikt.
2. Webserver - De webserver neemt het verzoek en stuurt het naar de Rails-toepassing.
3. Router - De router, het eerste deel van de Rails-applicatie dat het verzoek ziet, het verzoek parseert en bepaalt welk controller/actie-paar het moet aanroepen.
4. Controller - De controller wordt aangeroepen. De taak van de controller is om gegevens op te halen met behulp van het model en deze naar een weergave te sturen.
5. Model - Als er gegevens moeten worden opgehaald, wordt het model gebruikt om gegevens uit de database te halen.
6. Weergave - De gegevens worden naar een weergave gestuurd, waar HTML-uitvoer wordt gegenereerd.
7. Web Server - De gegenereerde HTML wordt teruggestuurd naar de server, Rails is nu klaar met het verzoek.
8. Webbrowser - De server stuurt de gegevens terug naar de webbrowser en de resultaten worden weergegeven.