Фултон Хэл — Программирование на языке Ruby

Отметим также, что эти библиотеки можно до определенного предела «смешивать». Вспомогательные функции из

, например метод , можно использовать автономно (не делая библиотеку основой приложения). Тогда предыдущий пример оказался бы несколько проще для восприятия.

19.3. Ruby on Rails

В сообществе пользователей Ruby одним из самых широко известных каркасов для Web является Ruby on Rails (или просто Rails). Его автор Дэвид Хайнемайер Хансон (David Heinemeier Hansson).

В каркасе Rails широко используются динамические свойства Ruby. У него также есть собственная философия, направленная на быструю разработку Web-приложений.

Rails хорошо известен и прекрасно документирован. В этой книге мы рассмотрим его лишь поверхностно.

19.3.1. Принципы и техника

Каркас Rails построен на основе паттерна Модель-Вид-Контроллер (Model-View-Controller — MVC). Каждое приложение естественно разбивается на модели (моделирующие предметную область), виды (с помощью которых информация представляется пользователю и организуется возможность взаимодействия) и контроллеры (играющие роль арбитров между моделями и видами).

В основу поведения Rails как каркаса положены определенные принципы. Один из них — «принцип минимизации кода»: не пишите код для связывания одного с другим, если такое связывание можно организовать автоматически.

С ним также связан принцип «примата соглашений над конфигурацией». Придерживаясь ряда заранее оговоренных стилей кодирования и именования, можно обойтись почти без конфигурирования (и приблизиться к идеальной среде с «нулевым конфигурированием»).

Rails прекрасно справляется с автоматизацией не слишком сложных задач. Если это имеет смысл, он сам генерирует код, избавляя программиста от необходимости писать его вручную.

Web-приложения часто хранят данные в базе, и Rails обеспечивает бесшовную интеграцию с базой данных. У Web-каркасов наблюдается тенденция проявлять «склонность» к какому-то конкретному объектно-реляционному отображению (object-relational mapper, ORM), и Rails — не исключение. Стандартным для Rails является отображение ActiveRecord, которое мы рассматривали в главе 10.

Базы данных описываются в файле

— одном из немногих необходимых конфигурационных файлов (конечно же, в формате YAML). В нем перечислены три разных базы данных: для разработки, для тестирования и для промышленной эксплуатации. На первый взгляд, это перебор, но в действительности такая схема оказывается очень удобной.

Rails генерирует для вас пустые модели и контроллеры. В ходе редактирования моделей вы определяете связи между таблицами базы данных с помощью таких методов, как

и (на самом деле их гораздо больше). Поскольку между моделями и таблицами есть соответствие, то написанный вами код заодно определяет и связи между самими моделями. Для контроля данных служат такие методы, как (проверяет, что данные присутствуют) и (проверяет, что данные уникальны).

В результате создания приложения Rails командой вида

вы получаете каталог с такой структурой:

Большая часть кода находится в каталоге

. Как видите, сама его структура следует паттерну MVC.

Схемы баз данных находятся в каталоге

. Инкрементные файлы миграции тоже попадут сюда.

В Rails есть концепция «обстраивания» (scaffolding), которая очень упрощает жизнь. Если ввести команду

( — имя модели), то для таблицы (обратите внимание на множественное число) будет сгенерирована функциональность «создать-обновить-удалить».

Можно обстроиться и не генерируя никакой код, достаточно вызвать внутри контроллера

метод :

Здесь мы достигаем той же цели, но не записываем никакой код на диск. Оба способа допустимы. Конечно, в результате обстраивания создаются страницы ввода/обновления, которые вполне функциональны, но не слишком красивы; почти всегда вы захотите заменить их чем-то более симпатичным. Тем не менее такая техника взаимодействия с базой данных полезна, особенно на этапе разработки.

В старых версиях Rails расхождение между ActiveRecord и базой данных было более существенным. Недавно появившаяся концепция миграции делает управление базой данных проще. То же касается и уже существующих в базе данных таблиц, работать с которыми было трудно; сейчас можно создать файл

, в котором будет перечислены все существующие таблицы (см. также и ).

19.3.2. Тестирование и отладка приложений Rails

В Rails встроена серьезная поддержка тестирования. Обратите внимание на каталог

, который создается для каждого нового приложения. Он заполняется по мере развития приложения; вы можете (и должны) добавлять тесты по ходу создания новой функциональности.

По принятому в Rails соглашению, автономные тесты служат для тестирования моделей, а функциональные — для тестирования контроллеров. Этим объясняется наличие подкаталогов

и в каталоге . (Вне контекста Ruby on Rails эти термины используются несколько иначе.)

Для тестирования в Rails большое значение имеет понятие стенда. Стенд (fixture) — это моментальный снимок начального содержимого модели, иными словами, набор фиктивных данных для тестирования. Все данные такого рода хранятся в формате YAML в файлах, расположенных в каталоге

.

Каталог

предназначен для хранения кода, играющего роль объекта-заглушки. Заглушки служат для имитации еще не реализованного сервиса или класса. Считайте это подобием голливудской декорации, которая только внешне похожа на реальность. Классический пример — шлюз в систему обработки кредитных карт; с помощью заглушек мы можем протестировать взаимодействие с ним, не имея настоящего шлюза.