Przepływ aplikacji Ruby on Rails

mihailomilovanovic/Getty Images

01 z 07

Przepływ aplikacji Rails

Kiedy piszesz własne programy od początku do końca, łatwo to zauważyć Kontrola przepływu . Tutaj zaczyna się program, tam jest pętla, są wywołania metod, wszystko jest widoczne. Ale w aplikacji Rails sprawy nie są takie proste. Przy wszelkiego rodzaju ramach rezygnujesz z kontroli nad takimi rzeczami jak „przepływ” na rzecz szybszego lub prostszego sposobu wykonywania złożonych zadań. W przypadku Ruby on Rails, kontrola przepływu jest obsługiwana za kulisami, a wszystko, co pozostaje, to (mniej więcej) kolekcja modeli, widoków i kontrolerów.

02 z 07

HTTP

Rdzeniem każdej aplikacji internetowej jest HTTP. HTTP to protokół sieciowy używany przez przeglądarkę internetową do komunikacji z serwerem sieciowym. Stąd pochodzą terminy takie jak „żądanie”, „GET” i „POST”, które są podstawowym słownictwem tego protokołu. Jednakże, ponieważ Railsy są tego abstrakcją, nie będziemy spędzać dużo czasu na rozmawianiu o tym.

Gdy otworzysz stronę internetową, klikniesz łącze lub prześlesz formularz w przeglądarce internetowej, przeglądarka połączy się z serwerem sieciowym za pośrednictwem protokołu TCP/IP. Przeglądarka wysyła następnie do serwera „żądanie”, pomyśl o tym jak o formularzu pocztowym, który przeglądarka wypełnia, prosząc o informacje na określonej stronie. Serwer ostatecznie wysyła do przeglądarki internetowej „odpowiedź”. Ruby on Rails nie jest jednak serwerem WWW, serwer WWW może być dowolnym serwerem Webrick (co zwykle dzieje się, gdy uruchamiasz serwer Rails z wiersz poleceń ) do Apache HTTPD (serwera internetowego, który obsługuje większość sieci). Serwer WWW jest tylko ułatwieniem, pobiera żądanie i przekazuje je do aplikacji Railsowej, która generuje odpowiedź i przekazuje ją z powrotem do serwera, który z kolei odsyła je z powrotem do klienta. Tak więc dotychczasowy przepływ to:

Klient -> Serwer -> [Rails] -> Serwer -> Klient

Ale „Rails” jest tym, co nas naprawdę interesuje, zajrzyjmy głębiej.

03 z 07

Router

Jedną z pierwszych rzeczy, które aplikacja Railsowa wykonuje z żądaniem, jest wysłanie go przez router. Każde żądanie ma adres URL, który pojawia się w pasku adresu przeglądarki internetowej. Router jest tym, co określa, co należy zrobić z tym adresem URL, czy adres URL ma sens i czy adres URL zawiera jakiekolwiek parametry. Router jest skonfigurowany w config/routes.rb .

Po pierwsze, wiedz, że ostatecznym celem routera jest dopasowanie adresu URL do kontrolera i akcji (więcej o tym później). A ponieważ większość aplikacji Railsowych jest RESTful, a rzeczy w aplikacjach RESTful są reprezentowane przy użyciu zasobów, zobaczysz linie takie jak zasoby :posty w typowych aplikacjach Railsowych. To pasuje do adresów URL, takich jak /posty/7/edytuj z kontrolerem Posts, edytować akcja na poczcie o identyfikatorze 7. Router decyduje, dokąd kierują żądania. Tak więc nasz blok [Rails] można nieco rozszerzyć.

Router -> [Szyny]

04 z 07

Kontroler

Teraz, gdy router zdecydował, do którego kontrolera wysłać żądanie i do której akcji na tym kontrolerze, wysyła je. Kontroler to grupa powiązanych akcji, które są zebrane razem w klasie. Na przykład w blogu cały kod do przeglądania, tworzenia, aktualizowania i usuwania wpisów na blogu jest spakowany w kontrolerze o nazwie „Post”. Działania są po prostu normalne metody tej klasy. Kontrolery znajdują się w aplikacja/kontrolery .

Załóżmy więc, że przeglądarka internetowa wysłała prośbę o /posty/42 . Router decyduje, że odnosi się to do Poczta kontroler, pokazać metoda i identyfikator posta do pokazania to 42 , więc nazywa się pokazać metoda z tym parametrem. The pokazać Metoda nie odpowiada za używanie modelu do pobierania danych i używanie widoku do tworzenia danych wyjściowych. Tak więc nasz rozszerzony blok [Rails] to teraz:

Router -> Kontroler#akcja

05 z 07

Modelka

Model jest zarówno najprostszy do zrozumienia, jak i najtrudniejszy do wdrożenia. Model odpowiada za interakcję z bazą danych. Najprostszym sposobem wyjaśnienia tego modelu jest prosty zestaw wywołań metod, które zwracają zwykłe obiekty Ruby, które obsługują wszystkie interakcje (odczyt i zapis) z bazy danych. Więc podążając za przykładem bloga, API, którego kontroler użyje do pobrania danych za pomocą modelu, będzie wyglądać mniej więcej tak: Post.find(parametry[:id]) . The param jest to, co router przeanalizował z adresu URL, Post jest modelem. To tworzy zapytania SQL lub robi wszystko, co jest potrzebne, aby pobrać post na blogu. Modele znajdują się w aplikacja/modele .

Należy zauważyć, że nie wszystkie czynności wymagają użycia modelu. Interakcja z modelem jest wymagana tylko wtedy, gdy dane muszą zostać załadowane z bazy danych lub zapisane w bazie danych. W związku z tym postawimy po nim znak zapytania w naszym małym schemacie blokowym.

Router -> Kontroler#akcja -> Model?

06 z 07

Widok

Wreszcie nadszedł czas, aby zacząć generować kod HTML. HTML nie jest obsługiwany przez sam kontroler ani przez model. Celem korzystania z frameworka MVC jest podzielenie wszystkiego na sekcje. Operacje na bazie danych pozostają w trybie, generowanie HTML pozostaje w widoku, a kontroler (wywoływany przez router) wywołuje je oba.

HTML jest zwykle generowany przy użyciu osadzonego Rubiego. Jeśli znasz PHP, to znaczy plik HTML z osadzonym w nim kodem PHP, osadzony Ruby będzie bardzo znajomy. Widoki te znajdują się w aplikacja/wyświetlenia , a kontroler wywoła jeden z nich w celu wygenerowania danych wyjściowych i odesłania go z powrotem do serwera WWW. Wszelkie dane pobrane przez kontroler przy użyciu modelu będą zazwyczaj przechowywane w zmienna instancji które dzięki magii Rubiego będą dostępne jako zmienne instancji z poziomu widoku. Ponadto osadzony Ruby nie musi generować kodu HTML, może generować dowolny rodzaj tekstu. Zobaczysz to podczas generowania XML dla RSS, JSON itp.

Dane wyjściowe są wysyłane z powrotem do serwera WWW, który odsyła je z powrotem do przeglądarki internetowej, która kończy proces.

07 z 07

Pełny obraz

I to wszystko, oto całe życie żądania do aplikacji webowej Ruby on Rails.

1. Przeglądarka internetowa - Przeglądarka wysyła żądanie, zwykle w imieniu użytkownika, gdy klika łącze.
2. Serwer WWW — serwer WWW pobiera żądanie i wysyła je do aplikacji Rails.
3. Router — router, pierwsza część aplikacji Rails, która widzi żądanie, analizuje żądanie i określa, którą parę kontroler/akcja ma wywołać.
4. Kontroler - Kontroler jest nazywany. Zadaniem kontrolera jest pobieranie danych za pomocą modelu i wysyłanie ich do widoku.
5. Model — jeśli konieczne jest pobranie jakichkolwiek danych, model jest używany do pobierania danych z bazy danych.
6. Widok — dane są wysyłane do widoku, w którym generowane są dane wyjściowe HTML.
7. Serwer internetowy - Wygenerowany kod HTML jest odsyłany do serwera, Railsy kończą teraz z żądaniem.
8. Przeglądarka internetowa - serwer odsyła dane z powrotem do przeglądarki internetowej, a wyniki są wyświetlane.