4 Генерация временных платформ
Сейчас мы сгенерируем временные платформы для разрабатываемой нами ИС. Во временную платформу входят модель, котроллер и представление для работы с ресурсами, это основное, что еще будет включаться, мы рассмотрим позже.
Фреймворк Ruby on Railsподдерживает структуру MVCприложений: Model (модель)- View(представление)-Controller(контроллер).
Приложенияразбиваются на компоненты трех типов: модели, представления и контроллеры.Концепция MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента.
Модель отвечает за поддержку состояния приложения. Иногда это состояниеявляется кратковременным, продолжающимся только на время нескольких взаимодействий с пользователем. А иногда состояние является постоянным и сохраняетсявне приложения, чаще всего в базе данных.Модель — это не просто данные; в ней прописаны все правила, применяемые к этим данным (ограничения на значения и т.п).
Представление отвечает за формирование пользовательского интерфейса, который обычно основан на данных модели. Например, список сотрудников должен отображаться на экране. Этот список будетдоступен через модель, но получать его у модели и форматировать для показа конечному пользователю будет представление. Хотя представление может предлагатьпользователю различные способы ввода данных, оно никогда не занимается их непосредственной обработкой. Работа представления завершается, как только данныебудут отображены на экране.
Контроллеры организуют работу приложения. Они воспринимают событиявнешнего мира (обычно ввод данных пользователем), взаимодействуют с модельюи отображают соответствующее представление для пользователя.
Взаимодействие этих трех элементов концепции показано нарис. 4.1.
Рисунок 4.1 – Порядок взаимодействия модели,представления и контроллера
За более подробной информацией настоятельно рекомендуем обратиться к литературе[2].
Поскольку мы создаем ИС у нас должны быть ее определенные элементы. Например, справочник должностей. Что в нем должно присутствовать? Во-первых, должна быть таблица в БД для работы с определенными атрибутами, но простому пользователю будет неудобно и не всегда возможно заносить новые объекты в таблицу в самой БД, поэтому следует проработать интерфейс для ИС, где можно будет создавать, изменять и удалять элементы этой таблицы. Это визуальная часть - представление. Как будет осуществляться сама работа методов добавления, изменения и удаления (CRUDсокращение)? Все методы хранятся в файле котроллеров. А конкретно создание нового ресурса «Должности» и его схемы будет храниться в файлах модели.
Для разрабатываемой ИС «Сотрудники» требуется создать 4 справочника и 2 отчета. Списки должностей, сотрудников, хобби, связи хобби с сотрудниками. Отчеты: популярность и увлеченность хобби.
Рисунок 4.2 – Схема БД
Таблица 4.1 – Таблица Должностей
Название таблицы |
Название поля |
Тип поля |
Примечание |
dlzh (Должности) |
ID |
Integer |
Генерируется самостоятельно |
d_name (Название должности) |
string |
|
|
status |
boolean |
|
|
s_delete |
boolean |
|
|
created_at |
timestamp |
Генерируется самостоятельно |
|
updated_as |
timestamp |
Генерируется самостоятельно |
Таблица 4.2 – Таблица Сотрудники
Название таблицы |
Название поля |
Тип поля |
Примечание |
sotr (Сотрудники) |
ID
|
Integer |
Генерируется самостоятельно |
s_fam (Фамилия) |
string |
|
|
s_name (Имя) |
string |
|
|
s_otch (Отчество) |
string |
|
|
s_date (Дата рождения) |
Date |
|
|
dlzh (Должность) |
Belongs_to |
Берется из таблицы должности |
|
photo (Фотография) |
string |
|
|
status |
boolean |
|
|
s_delete |
boolean |
|
|
created_at |
timestamp |
Генерируется самостоятельно |
|
updated_as |
timestamp |
Генерируется самостоятельно |
Таблица 4.3 – Таблица Хобби
Название таблицы |
Название поля |
Тип поля |
Примечание |
hobby (Хобби)
|
ID |
Integer |
Генерирует самостоятельно |
h_name(Название хобби) |
string |
|
|
status |
boolean |
|
|
s_delete |
boolean |
|
|
created_at |
timestamp |
Генерируется самостоятельно |
|
updated_as |
timestamp |
Генерируется самостоятельно |
Таблица 4.4 – Таблица Увлечения сотрудников
Название таблицы |
Название поля |
Тип поля |
Примечание |
hobby_sotr (Увлечения сотрудников) |
ID Сотрудника
|
belongs_to |
Берется из таблицы сотрудники |
ID Хобби
|
belongs_to |
Берется из таблицы хобби |
|
status |
boolean |
|
|
s_delete |
boolean |
|
|
created_at |
timestamp |
Генерируется самостоятельно |
|
updated_as |
timestamp |
Генерируется самостоятельно |
Итак, проделаем следующие шаги:
Создадим так называемую платформу (scaffold).Она будет сразу же состоять из модели, представления и контроллера. Команда для генерации временной платформы:
rails generate scaffold Dlzh d_name:string status:boolean s_delete:boolean
Разберем команду подробнее. Generate scaffold заставляет Rails сгенерировать новую временную платформу, Dlzh это название, причем модель ресурсов, а значит и таблица в БД будет автоматически переименована во множественном числе, т.е. dlzhs, d_name – название атрибута, - string тип данных, свойства status, s_delete мы будем использовать в дальнейшем, при изучении раздела многопользовательского режима. Все типы данных поддерживаемых в Rails приведены в таблице 4.1.
Таблица4.5 – ТипыданныхвRoR
RoR |
PostgreSQL |
:binary |
Blob |
:boolean |
Boolean |
:date |
Date |
:datetime |
Timestamp |
:decimal |
Decimal |
:float |
Float |
:integer |
Integer |
:string |
String |
:text |
Text |
:time |
Time |
:timestamp |
Timestamp |
Если вы все сделали правильно, т.е. в консоли должны появиться следующие строчки (Рисунок 4.3).
Рисунок 4.3 – Создание временной платформы должности сотрудников
При генерации платформы был создан файл-миграция, в нем находятся сведения о структуре таблицы, которые необходимо внести в БД. Для этого пропишем в консоли следующую команду:
rake db:migrate
Если миграция прошла успешно, то файл лежащий в папке db/migrate/ (папка с миграциями) должен быть выполнен, после чего в БД создастся таблица dlzhs. Проверить факт наличия таблицы dlzhs можно, открыв pgAdmin (если pgadmin был открыт, то обновить все объекты БД кнопкой «Обновить») и зайдя в БД «Sotrudniki», в ветке таблицы найти эту таблицу.
Рисунок 4.4 – Проверка содержимого БД
Как видите,Ruby on Rails создал поле ID(идентификатор) и некоторые другие поля самостоятельно.
Примечание:
Тема миграций в Ruby on Rails является довольно широкой, содержащей много различных нюансов и функций, поэтому настоятельно рекомендуем ознакомиться с темой, в литературе[2], приведенной в конце методических указаний.
Для того чтобы среда Ruby on Rails адекватно реагировала на все изменения, лучше ВСЕ делать с помощью миграций.
Примечание :
Если по какой либо причине, Вы что-то сделали не корректно, например, забыли добавить столбец s_delete в таблицу dlzhs не огорчайтесь, поправить ситуацию достаточно просто. Лучше выполнить процедуру добавления столбца с помощью миграций (т.к. это позволит контролировать и делать все необходимые изменения в БД непосредственно средой RubyonRace).
В этом случае необходимо с помощью консольного приложения добавить новую миграцию.
Для этого генерируем миграцию с именем (например s_delete_dlzhs) rails g migration s_delete_dlzhs
Затем в текстовом редакторе (в нашем случаеSublimeText 2) найти данную миграцию и прописываем недостающий столбец s_delete.
Далее в командной строке необходимо выполнить все миграции
rake db:migrate
Если миграций очень много, то можно выполнить только необходимую.
rake db:migrate s_delete_dlzhs
Проверяем в pgAdmin добавление необходимого столбца (смотри рисунок ).
Далее командой rails s запускаем сервер и проверяем работу на localhost:3000.
Аналогичные действия можно предпринимать при изменении, удалении столбцов и т.п. При этом естественно использовать соответствующие методы.
Создадим остальные платформы. Запишем последовательно в консоли (не забывая затем выполнять команду добавления миграций в БД (rake db:migrate):
Для создания платформы Sotr:
rails generate scaffold Sotr s_fam:string s_name:string s_otch:string s_date:date dlzh:belongs_to photo:string status:boolean s_delete:boolean
Для создания платформы Hobby:
rails generate scaffold Hobby h_name:string status:boolean s_delete:boolean
Для создания платформы Hobby_sotr:
Rails generate scaffold Hobby_sotr sotr:belongs_to hobby:belongs_to status:boolean s_delete:boolean
Все это должно согласовываться с нашей схемой БД, приведенной выше на рисунке 4.2
Как вы могли заметить в некоторых записях стоит тип данных belongs_to, с его помощью формируется внешний ключ, на тот id таблицы, который соответствует названию. И если вы заглядывали в БД, чтобы проверить наличие созданных таблиц, то могли увидеть, что атрибут idсоздается автоматически. Подробнее тему связей таблиц в RoRможно изучить в документации по RubyonRailsв разделе «Связи Active Record»[1].
Давайте проверим результат работы. Запустите сервер и наберите адрес в браузере localhost:3000/sotrsи так отдельно для каждой платформы (Рисунок 4.5).
Рисунок 4.5 – Страничка справочника сотрудники
Попробуйте добавлять, изменять, удалять элементы на разных справочниках. Не забывайте при этом, что сначала надо добавлять сведения в «родительские» справочники, а уже затем в «дочерние».
Так сначала нужно заполнить справочник «Должности» (dlzch) и «Хобби» (hobbys), затем справочник «Сотрудники» (sotrs), а затем уже справочник «Сотрудник-Хобби» (hobby-sotrs).
Примечание:
Если при открытии страницы у вас выведет ошибку, прочитайте внимательно ее содержание, а также узнайте ее место (строка и файл будут указаны).