Когато пишете свои програми от началото до края, това е лесно да се види контрол на потока. Програмата стартира тук, има цикъл там, обажданията на методи са тук, всичко се вижда. Но в приложението Rails нещата не са толкова прости. С всякаква рамка вие се отказвате от контрола върху такива неща като "поток" в полза на по-бърз или по-прост начин за изпълнение на сложни задачи. В случая на Ruby on Rails контролът на потока се управлява зад кулисите и всичко, което ви остава, е (повече или по-малко) колекция от модели, изгледи и контролери.
В основата на всяко уеб приложение е HTTP. HTTP е мрежовият протокол, който уеб браузърът ви използва за разговор с уеб сървър. Оттук идват термини като „заявка“, „GET“ и „POST“, те са основният речник на този протокол. Въпреки това, тъй като Rails е абстракция на това, няма да отделим много време за това.
Когато отворите уеб страница, щракнете върху връзка или изпратете формуляр в уеб браузър, браузърът ще се свърже към уеб сървър чрез TCP / IP. След това браузърът изпраща на сървъра "заявка", мислете за това като формуляр за поща, който браузърът попълва, като иска информация на определена страница. В крайна сметка сървърът изпраща на уеб браузъра "отговор". Ruby on Rails обаче не е уеб сървърът, уеб сървърът може да бъде всичко от Webrick (какво обикновено се случва, когато стартирате Rails сървър от на
командна линия) до Apache HTTPD (уеб сървър, който захранва по-голямата част от мрежата). Уеб сървърът е просто фасилитатор, той взема заявката и я предава на вашето приложение Rails, който генерира отговора и преминава се връща към сървъра, който от своя страна го изпраща обратно към клиент. Така че потокът досега е:Едно от първото нещо, което приложение Rails прави с искане, е да го изпрати през рутера. Всяка заявка има URL адрес, това се показва в адресната лента на уеб браузър. Рутерът е това, което определя какво трябва да се направи с този URL адрес, ако URL адресът има смисъл и ако URL адресът съдържа някакви параметри. Рутерът е конфигуриран в конфигурационния / routes.rb.
Първо, знайте, че крайната цел на рутера е да съпостави URL адрес с контролер и действие (повече за тях по-късно). И тъй като повечето приложения на Rails са RESTful и нещата в RESTful приложения са представени с помощта на ресурси, ще видите редове като ресурси: публикации в типични приложения на Rails. Това съответства на URL адреси като /posts/7/edit с контролера за съобщения, редактиране действие по пощата с идентификационния номер от 7. Рутерът просто решава къде отиват заявките. Така че нашият [Rails] блок може да бъде разширен малко.
Сега, когато маршрутизаторът е решил на кой контролер да изпрати заявката и към кое действие на този контролер, той го изпраща. Контролер е група от свързани действия, всички групирани в клас. Например, в блог целият код за преглед, създаване, актуализиране и изтриване на публикации в блога се групира заедно в контролер, наречен „Публикуване“. Действията са просто нормални методи от този клас. Контролерите са разположени в ап / контролери.
Да речем, че уеб браузърът е изпратил заявка за /posts/42. Рутерът реши, че това се отнася за пост контролера, шоу метод и идентификационният номер на публикацията за показване е 42, така се нарича шоу метод с този параметър. Най- шоу метод не носи отговорност за използването на модела за извличане на данни и използване на изгледа за създаване на изход. Така че нашият разширен блок [Rails] вече е:
Моделът е едновременно най-простият за разбиране и най-труден за изпълнение. Моделът отговаря за взаимодействието с базата данни. Най-простият начин да се обясни е, че моделът е прост набор от извиквания на метод, които връщат обикновени Ruby обекти, които обработват всички взаимодействия (чете и записва) от базата данни. Така следвайки примера на блога, API, който контролерът ще използва за извличане на данни с помощта на модела, ще изглежда нещо като Post.find (params [: id]). Най- Поколения назад е това, което маршрутизаторът анализира от URL адреса, Post е моделът. Това прави SQL заявки или прави всичко необходимо за извличане на публикацията в блога. Моделите са разположени в ап / модели.
Важно е да се отбележи, че не всички действия трябва да използват модел. Взаимодействието с модела е необходимо само когато данните трябва да бъдат заредени от базата данни или запазени в базата данни. Като такъв, ние ще поставим въпросителен знак след него в нашата малка блок-схема.
И накрая, време е да започнете да генерирате малко HTML. HTML не се обработва от самия контролер, нито се обработва от модела. Смисълът на използването на MVC рамка е да разделим всичко. Операциите с база данни остават в режим, HTML генерирането остава в изгледа, а контролерът (наричан от рутера) ги извиква и двете.
HTML обикновено се генерира с помощта на вграден Ruby. Ако сте запознати с PHP, тоест HTML файл с PHP код, вграден в него, тогава вграденият Ruby ще бъде много познат. Тези изгледи се намират в ап / изгледии контролер ще извика един от тях, за да генерира изхода и да го изпрати обратно към уеб сървъра. Всички данни, извлечени от контролера, използващ модела, обикновено се съхраняват в примерна променлива които, благодарение на някои магии на Ruby, ще бъдат достъпни като променливи инстанции от изгледа. Освен това вграденият Ruby няма нужда да генерира HTML, той може да генерира всякакъв тип текст. Това ще видите, когато генерирате XML за RSS, JSON и т.н.
Този изход се изпраща обратно към уеб сървъра, който го изпраща обратно към уеб браузъра, което завършва процеса.