ORM

Материал из Википедии — свободной энциклопедии

ORM — (англ Object-relational mapping) технология в программировании, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая (как результат) «виртуальную объектную базу данных». Существуют как коммерческие, так и бесплатные реализации этой технологии.

[править] Проблема

В объектно ориентированном программировании, объекты в программе представляют объекты из реального мира. В качестве примера, можно рассмотреть адресную книгу которая содержит список людей вместе с нулём или более телефонов и нулём или более адресов. В терминах объектно ориентированного программирования, они будут представляться объектами класса «Человек», которые будут содержать следующий список полей: имя, список (или массив) телефонов и список адресов.

Суть проблемы состоит в преобразовании таких объектов в форму, в которой они могут быть сохранены в файлах или базах данных, и которые легко могут быть извлечены в последующем, с сохранением свойств объектов и отношений между ними. Эти объекты называют «постоянными» (англ. persistent). Исторически, существует несколько подходов к решению этой проблемы.

[править] Реляционные СуБД

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

Реляционные базы данных используют набор таблиц, представляющих простые данные. Дополнительная или связанная информация хранится в других таблицах. Часто для хранения одного объекта в реляционной базе данных используется несколько таблиц, это, в свою очередь, требует применение операции '«join» для получения всей, относящейся к объекту, информации для ее обработке. Например, в рассмотренном варианте с записной книгой, для хранения данных скорее всего будут использоваться как минимум две таблицы: люди и адреса, и, возможно, даже таблица с телефонными номерами.

Так как системы управления реляционными базами данных обычно не реализуют реляционного представления физического уровня связей, выполнение нескольких последовательных запросов (относящихся к одной «объектно-ориентированной» структуре данных) может быть слишком затратно. В частности, один запрос вида «найти такого-то пользователя и все его телефоны и всего его адреса и вернуть их в таком формате» скорее всего будет выполнен быстрее серии запросов вида «Найти пользователя. Найти его адреса. Найти его телефоны». Это происходит благодаря работе оптимизатора и затратам на парсинг запроса.

Некоторые реализации ORM автоматически синхронизируют загруженные в память объекты с базой данных. Для того, что бы это было возможным, после создания объект-в-SQL преобразующего SQL запроса, полученные данные копируются в поля объекта, как во всех других реализациях ORM. После этого, объект должен следить за изменениями этих значений и записывать их в базу данных.

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

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

[править] Решение

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

Некоторые реализации пытаются решить эту проблему, предоставляя библиотеки классов, способных выполнять эти преобразования автоматически. Имея список таблиц в базе данных и объектов в программе, они автоматически преобразуют запросы из одного вида, в другой. В результате запроса объекта человек (из примера с адресной книгой), необходимый SQL запрос будет сформирован и выполнен, а результаты «магическим» образом преобразованы в объекты номер телефона внутри программы.

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

На практике все не так просто и очевидно. Все системы ORM обычно проявляют себя в том или ином виде, уменьшая в некотором роде возможность игнорирования базы данных. Более того, слой транзакций может быть медленным и неэффективным (особенно в терминах сгенерированного SQL). Все это может привести к тому, что программы будут работать медленнее и использовать больше памяти, чем программы, написанные «вручную».

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