Архитектура. 
Использование программного интерфейса

В современной индустрии информационных технологий, связанных с разработкой веб-приложений часто используются «каркасы» (frameworks), которые задают общую архитектуру приложения. Например, Ruby on Rails, используемы для данного проекта, реализует архитектурный образец «модель-представление-контроллер» (model-view-controller, MVC).

«Концепция MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента:

• 1. Модель (англ. Model). Модель предоставляет знания: данные и методы работы с этими данными, реагирует на запросы, изменяя своё состояние. Не содержит информации, как эти знания можно визуализировать.
• 2. Представление, вид (англ. View). Отвечает за отображение информации (визуализацию). Часто в качестве представления выступает форма (окно) с графическими элементами.
• 3. Контроллер (англ. Controller). Обеспечивает связь между пользователем и системой: контролирует ввод данных пользователем и использует модель и представление для реализации необходимой реакции" [1]

Рис. 1 Схема взаимодействия компонентов в рамках архитектуры MVC

Ruby on Rails предоставляет разработчику возможность работать с объектами реляционной базы данных как с экземплярами класса в объектно-ориентированном программировании. Таблица реляционной базы данных представляется как класс, а строки таблицы, соответственно, как экземпляры класса. При вызове метода объекта, возвращающего значение его атрибутов, происходит считывание информации из базы данных. При создании экземпляра класса данные вносятся в таблицу реляционной базы данных.

Как было упомянуто выше, модель данных никак не участвует непосредственно в отображении информации, она лишь формирует необходимый объём данных по запросу контроллера.

Для вызова нужного контроллера в Rails используется специальный механизм маршрутизации, с помощью которого на основе запрашиваемого браузером URI (Uniform Resource Identifier, последовательность символов, идентифицирующая абстрактный или физический ресурс [1]) и http — метода запроса определяется, какое действие должно быть совершено. На основании этого выбирается нужный контроллер, обеспечивающий выполнение требуемого действия.

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

В упрощённом виде последовательность операций, которые совершает приложение, можно описать так:

• 1. От браузера поступает запрос на страницу, соответствующую определённой единице оборудовния. В нашем примере это будет /machinery/42.
• 2. В контроллере machinery программа находит действие show (показать).
• 3. С помощью действия show происходит обращение к модели machinery c целью получить информацию о сущности machinery c идентификатором 42.
• 4. Модель machinery выполняет соответствующий запрос к базе данных.
• 5. Модель возвращает контроллеру machinery полученную из запроса информацию.
• 6. В некой переменной контроллер передаёт представлению machinery полученные данные.
• 7. Представление генерирует визуализацию страницы с полученным от контроллера набором данных в HTML.
• 8. Контроллер возвращает браузеру сгенерированный представлением HTML-код страницы

Такая реализация приложения позволяет разделить процесс разработки — модели представления могут создаваться более-менее независимо. Для представления не важна внутренняя бизнес-логика модели, оно поучит от контроллера информацию в том виде, в котором она потребуется.

Из приведённого примера может сложиться мнение, что модель — это просто интерфейс для взаимодействия приложения с базой данных. На самом деле в моделях реализуется основная бизнес-логика приложения («совокупность правил, принципов, зависимостей поведения объектов предметной области"[1]), а как раз контроллеры являются интерфейсами для передачи данных и запросов между различными компонентами приложения. Компоненты-представлений не занимаются обработкой данных, только выводом в нужной для пользователя форме.