Когда вы пишете свои собственные программы от начала до конца, это легко увидеть управление потоком. Программа начинается здесь, там есть цикл, здесь вызовы методов, все это видно. Но в приложении 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 с контроллером сообщений, редактировать акция на Пост с ID 7. Маршрутизатор просто решает, куда отправляются запросы. Таким образом, наш блок [Rails] может быть немного расширен.
Теперь, когда маршрутизатор определил, какому контроллеру отправлять запрос и какому действию на этом контроллере он отправляет его. Контроллер - это группа связанных действий, связанных в один класс. Например, в блоге весь код для просмотра, создания, обновления и удаления сообщений блога объединен в контроллере под названием «Post». Действия просто нормальные методы этого класса. Контроллеры расположены в приложение / контроллеры.
Допустим, веб-браузер отправил запрос на /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 и т. Д.
Этот вывод отправляется обратно на веб-сервер, который отправляет его обратно в веб-браузер, который завершает процесс.