När du skriver dina egna program från början till slut är det lätt att se flödeskontroll. Programmet startar här, det finns en slinga där, metodsamtal är här, allt är synligt. Men i en Rails-applikation är saker inte så enkla. Med ett ramverk av vilket slag som helst släpper du kontroll över sådana saker som "flöde" till förmån för ett snabbare eller enklare sätt att utföra komplexa uppgifter. När det gäller Ruby on Rails hanteras flödeskontrollen allt bakom kulisserna, och allt du har kvar är (mer eller mindre) en samling modeller, vyer och kontroller.
Kärnan i alla webbapplikationer är HTTP. HTTP är nätverksprotokollet som din webbläsare använder för att prata med en webbserver. Det är här termer som "begäran", "GET" och "POST" kommer från, de är det grundläggande ordförrådet för detta protokoll. Men eftersom Rails är en abstraktion av detta kommer vi inte att spendera mycket tid på att prata om det.
När du öppnar en webbsida, klicka på en länk eller skicka in ett formulär i en webbläsare kommer webbläsaren att ansluta till en webbserver via TCP / IP. Webbläsaren skickar sedan servern en "begäran", tänk på den som en e-postformulär som webbläsaren fyller i och ber om information på en viss sida. Servern sänder slutligen webbläsaren ett "svar". Ruby on Rails är dock inte webbservern, webbservern kan vara allt från Webrick (vad som vanligt händer när du startar en Rails-server från de
kommandorad) till Apache HTTPD (webbservern som driver det mesta av webben). Webbservern är bara en underlättare, den tar begäran och överlämnar den till din Rails-applikation, vilket genererar svaret och passerar är tillbaka till servern, som i sin tur skickar tillbaka det till klient. Så flödet hittills är:En av de första saker som en Rails-applikation gör med en begäran är att skicka den via routern. Varje förfrågan har en URL, det är detta som visas i adressfältet i en webbläsare. Routern är det som avgör vad som ska göras med den webbadressen, om webbadressen är vettig och om webbadressen innehåller några parametrar. Routern är konfigurerad i config / routes.rb.
Först vet du att routerns slutliga mål är att matcha en URL med en controller och handling (mer om dessa senare). Och eftersom de flesta Rails-program är RESTful och saker i RESTful-applikationer representeras med hjälp av resurser ser du rader som resurser: inlägg i typiska Rails-applikationer. Detta matchar webbadresser som /posts/7/edit med Posts controller, the redigera handling på posten med ID 7. Routern bestämmer bara vart förfrågningar går. Så vårt [Rails] -block kan utökas lite.
Nu när routern har beslutat till vilken controller som ska skickas förfrågan till och vilken åtgärd på den regulatorn skickar den den. En Controller är en grupp relaterade åtgärder som alla samlas i en klass. Till exempel, i en blogg, samlas all kod för att visa, skapa, uppdatera och ta bort blogginlägg i en controller som heter "Post". Åtgärderna är helt normalt metoder av denna klass. Kontroller finns i app / controllers.
Så låt oss säga att webbläsaren skickade en begäran om /posts/42. Routern bestämmer att detta hänvisar till Posta styrenhet, visa metod och ID för inlägget som ska visas är 42, så det kallar visa metod med denna parameter. De visa metoden är inte ansvarig för att använda modellen för att hämta data och använda vyn för att skapa utdata. Så vårt utvidgade [Rails] -block är nu:
Modellen är både den enklaste att förstå och svårast att implementera. Modellen ansvarar för att interagera med databasen. Det enklaste sättet att förklara den är modellen är en enkel uppsättning metodsamtal som returnerar vanliga Ruby-objekt som hanterar alla interaktioner (läser och skriver) från databasen. Så efter bloggexemplet kommer API: en som kontrollenheten använder för att hämta data med hjälp av modellen se ut som Post.find (params [: id]). De params är vad routern har analyserat från URL: n, Post är modellen. Detta gör SQL-frågor eller gör vad som krävs för att hämta blogginlägget. Modeller finns i app / modeller.
Det är viktigt att notera att inte alla åtgärder behöver använda en modell. Att interagera med modellen krävs endast när data måste laddas från databasen eller sparas i databasen. Som sådan kommer vi att sätta ett frågetecken efter det i vårt lilla flödesschema.
Slutligen är det dags att börja generera HTML. HTML hanteras inte av styrenheten själv, och den hanteras inte heller av modellen. Poängen med att använda ett MVC-ramverk är att dela upp allt. Databasåtgärderna förblir i läget, HTML-generationen förblir i vyn, och styrenheten (kallas av routern) kallar dem båda.
HTML genereras normalt med inbäddad Ruby. Om du är bekant med PHP, det vill säga en HTML-fil med PHP-kod inbäddad i den, då är den inbäddade Ruby mycket bekant. Dessa vyer finns i app / vyeroch en styrenhet kommer att ringa en av dem för att generera utdata och skicka tillbaka den till webbservern. All data som hämtas av regulatorn som använder modellen lagras vanligtvis i ett instansvariabel vilket, tack vare Ruby magi, kommer att vara tillgängligt som instansvariabler från vyn. Inbäddad Ruby behöver inte generera HTML, det kan generera någon typ av text. Det ser du när du skapar XML för RSS, JSON, etc.
Denna utgång skickas tillbaka till webbservern, som skickar tillbaka den till webbläsaren, som slutför processen.