OlegTar
@OlegTar
программист .NET, Javascript, Perl

Для чего нужна ORM?

Нет, я не пойму зачем заменять SQL язык своим?
Зачем надо делать класс, методы которого принимают имя таблицы, принимают условие для фраз WHERE, GROUP BY, HAVING.

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

Так в чём профит?
  • Вопрос задан
  • 21644 просмотра
Решения вопроса 1
Вы не путаете ORM с DBAL? ORM это не технология замены SELECT * FROM goods WHERE cost < 100.00 на $db->select()->from('goods')->where('cost < 100.00'). ORM это способ задания связи объектов и РСУБД. По сути позволяет абстрагироваться от способа хранения объектов вообще, с лёгкостью переходя от SQL к NoSQL, memcache, файлам или REST/RPC API на удалённом сервере, оперируя на уровне модели (если говорить о MVC и т. п.) простыми plain old objects, а их персистентность отдать контроллеру. Не $db->select()->from('goods'),, не mysql_query('SELECT * FROM goods'), а $goodsRepository->findAll(), а уж будет репозиторий формировать SQL запрос, читать файлы или память, а может стучаться на Гугл и парсить его вывод — его, репозитория, личное дело (а также разработчика(ов), отвечающих за подсистему хранения).

Кроме того ORM, как правило не исключает обращение к БД на уровне произвольных SQL запросов, оно лишь преобразуют результаты этих запросов в объекты модели предметной области (и наоборот), которые ничего не знают (в идеале) о таблицах, WHERE, HAVING и т. п.

ORM это не только инструмент архитектурного разделения областей ответственности объектов и классов приложения, а также инструмент облегчения разделения труда разработчиков: кто хорошо шарит в SQL вообще и особенностях конкретного движка в частности — работает по «ту сторону» ORM, оптимизирует его как хочет, может нормализовывать и денормализовывать, например; кто хорошо разбирается в дебетах и кредитах — работает с plain old objects в терминах предметной области и может вообще ничего не зная об SQL, ему лишь нужно знать, что он всегда может получить объект или их коллекцию обратившись к методам вроде findById() или findAll() и сохранить результат работы методом save() или flush().
Ответ написан
Пригласить эксперта
Ответы на вопрос 12
Zorkus
@Zorkus
Сам по себе ORM, именно как maaping, в крупных проектах нужен как раз очень сильно. Опишу здесь свой опыт. Если понравится кому, может и статью потом.

Итак.
Представьте себе — у меня есть очень крупная система, и есть в ней таблица orders, в ней скажем, 50 колонок (на самом деле у нас 150, ну да ладно. Нормализаторы, молчать! Про нормальные формы я тоже знаю). И вот надо значит вам выбрать один ордер и показать его на экране. Допустим, вы пишете селект, неважно. Дальше что делать, в промежуточном слое? Вы не же вызываете хранимую процедуру (запрос) напрямую с, скажем, JSP страницы (я надеюсь), вам все равно надо получить данные и передать их как-то.
Так что, передавать их в виде массива, ArrayList-a, ассоциативного массива имя колонки/значения? Ну так дико громоздно, неудобно, и очень легко ошибиться. А если вам надо несколько ордеров, тогда что, создавать вложенные коллекции для конвертации результатов? Неудобно же.

Потому, очевидно, нам нужен объект Order, имеющий все нужные property, и нужен код, который умеет конвертировать результаты скл запрос в эти объекты (или коллекцию этих объектов).

Далее, очевидно, что писать руками _все_ запросы трудно и нудно, легко ошибиться, т.к. в Java они будут представляться в коде в виде строк (а значит, никакой статической типизации и compile-time проверок и прочее и прочее), и их надо держать либо в Java коде (если они мелкие), либо, если побольше, выносить в отдельные XML файлы.

В общем, ORM в больших проектах нужен для упрощения рутинной части. Без него — никуда :)

Безусловно, обойтись ТОЛЬКО ORM не получится. Есть у нас масса мест, где сложная логика написана в хранимых процедурах в 500-1000 строк на PL/SQL, написанная через ORM /Java она бы занимала в 10 раз больше и работала в 2 раза медленнее (при этом, она была бы еще и менее понятная, т.к. есть такая логика, которые в терминах реляционной алгебры описывается куда проще, чем в терминах ООП :), следовательно ложится на ORM со скрипом). Сколько нибудь сложные запросы с подзапросами, юнионами, хитрыми джойнами тоже писать через чистый ORM громоздко. Оптимизировать запросы, работающими в таблицах где, хотя бы, несколько сотен миллионов записей, без доступа к планам SQL оптимизатора и статистики/средствам мониторинга уровня СУБД тоже крайне сложно. Так что без SQL тоже — никуда :)
Ответ написан
@phasma
> Так в чём профит?

Вы пробовали поддерживать проект, который поддерживает 5-6 СУБД?
Ответ написан
WebByte
@WebByte
По моему скромному мнению, ORM придумали люди, которым сложновато мыслить теорией множеств, что необходимо для понимания и правильного применения SQL.

Практической пользы от ORM в серьезных проектах чуть меньше, чем от какого-нибудь, прости, Господи, скрама.
В мелких — реальная польза лишь в том, что кто-то будет себя считать крутым ООП-программистом.

Как всегда, рекомендую статью:
citforum.ru/database/articles/vietnam/
Ответ написан
simplecode
@simplecode
некий интерфейс для работы с данными, которые не важно в каком виде и где находятся… в коде очень удобно работать с объектом, который представляет некоторый набор данных…
Ответ написан
@smartly
Чтобы писать запросы на своём языке программирования, а не интегрировать в исходник ещё один язык.
Ответ написан
@kirsan_vlz
У меня в проекте есть много однотипных модулей, которые представляют объекты. Можно выбирать из базы один объект, можно выбирать много объектов. Всё это по любому полю или совокупности полей. И вот раньше приходилось на каждый такой модуль писать кучу однотипных запросов для всех этих действий. После внедрения ОРМ стоит только добавить несколько строк настройки в модуль и все эти методы сразу становятся доступны. То есть разработка становится быстрее за счёт устранения рутины. Совсем уж сложные запросы пишем, само собой на чистом SQL, а вот простые ORM выполняет на ура.
Ответ написан
@pil0t
Используем C#, DataObjects.Net
ORM с методолгией CodeFirst значительно упрощает поддержку БД.
Примеры:
1. Удалили поле из таблицы — нам нужно каким-то хитрым образом проверить все запросы которые могут использовать это поле. В случае работы через ORM мы уже на этапе компиляции не сможем написать неправильный запрос.
2. Переименование поля — при ORM можем пользоваться всеми возможностями таких штук как Resharper, и автоматом переименовывать там где надо.
3. Не самая высокая оптимальность запросов через ORM частично компенсируется возможностью кэширования на appserv, а так же возможностью выполнения части запросов на appserv (с учетом легкой масштабируемости последнего)
4. В качестве доп. бонуса, хотя и не особо используемого нами — получаем переносимость на другие БД
Ответ написан
Melanitsky
@Melanitsky
Для простых запросов это удобней. Вы просто собираете запрос как конструктор, INSERT и UPDATE также невероятно удобен. Просто передать ассоциативный массив в качестве аргумента. По крайнем мере так в Zend_DB.
А сложные и вложенные запросы все ровно приходиться писать ручками.
Ответ написан
kefirr
@kefirr
Что значит — зачем? Чтобы представлять результаты запросов в виде объектов языка. А как ещё вы предлагаете работать с результатами запросов?

Давайте предметно рассуждать. Покажите код, который делает запрос и показывает результаты пользователю. И посмотрим, можно ли этот код сделать лучше при помощи ORM.

PS Я работаю с Entity Framework 4.0, и он великолепен.
Ответ написан
freeAKK
@freeAKK
ORM нужен тогда, когда время жизни объектов выборки сильно больше чем время самой выборки. В таких случаях затраты на выборку объектов со всеми потрохами (JOIN-ы) незначительно сказываются на скорость, а сохранить состояния объектов очень просто. Т.е. потребность в ORM возникает в «долгоживущих» программах, в которых РСУБД это просто место, где мы можем сохранить свои объекты.
В случаях, когда нужно отработать быстро, sql (DBAL) незаменим.
Ответ написан
variable
@variable
Тот-же самый фреймворк, только для базы. Использование фреймворков не оправданно?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы