Каковы ограничения ORM в целом?

Question

Я знаю, что есть много поклонников ORM, но как вы справляетесь с базой данных с более чем 300 таблицами, а некоторые таблицы имеют более 100 полей?

Большинство примеров приложений, которые я видел, используют только несколько полей. Целесообразно ли использовать ORM в таких масштабах? Я думаю, что ORM избыточен (зачем создавать другой слой, когда в реальности базы данных не меняются легко?).

Для меня имеет смысл использовать ORM для небольших приложений, которые могут перемещаться из баз данных в базы данных, или приложений, которые можно запускать на нескольких платформах.

В противном случае это кажется бесполезным или просто еще одна головная боль.

есть идеи?

Answer 1

Я использовал ORM в некоторых проектах (Hibernate), а не в других. Ограничения ORM такие же, как и для всех абстракций, вы отказываетесь от некоторой гибкости и должны вкладывать средства в изучение специфики реализации. Однако вы, как правило, получаете эффективность кодирования, уменьшаете дублирование, централизуете конфигурацию и получаете другие улучшения, характерные для реализации. Обратите внимание, что переносимость базы данных не всегда без усилий - очевидно, нет, если вы используете специфические для поставщика функции.

Вы не упоминаете, имеет ли ваш проект реализацию доступа к данным. Если вы начинаете с нуля, то размер базы данных не должен вас сильно беспокоить, поскольку ORM на самом деле должен сэкономить вам большую базу данных с точки зрения эффективности и уменьшения дублирования. Однако, если вы планируете заменить существующую реализацию доступа к данным и не предвидите, что база данных сильно изменится, ваши усилия почти наверняка перевесят преимущества.

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

Answer 2

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

т.е. иногда ваш бизнес-объект может быть довольно сложным или использовать несколько таблиц базы данных (т.е. @SecondaryTable в JPA 2.0). Вам не нужно знать, как объект представлен в базе данных, чтобы выполнять свою работу.

А как насчет отношений? Как разработчику, мне не нужно знать, реализована ли связь в виде таблицы соединений, внешнего ключа или чего-либо еще. Мне просто нужно установить соответствующие объектно-ориентированные ассоциации, и ORM сделает всю остальную работу за меня.

Я видел довольно большие проекты (> 50 разработчиков), которые отлично работали на ORM, даже в то время, когда инструменты не были такими хорошими и зрелыми, как сейчас.

Возможно, вы захотите увидеть эту тему: Подходит ли ORM для сложных проектов?