Есть ли веские причины не использовать ORM? [закрыто]


107

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

Однако я не совсем понимаю две основные причины, по которым я не использую NHibernate или аналогичный проект:

  1. Можно просто создать собственные объекты доступа к данным с помощью SQL-запросов и скопировать эти запросы из Microsoft SQL Server Management Studio.
  2. Отладка ORM может быть сложной.

Итак, конечно, я мог бы просто создать свой уровень доступа к данным с большим количеством SELECTs и т. Д., Но здесь я упускаю преимущества автоматических соединений, ленивых классов прокси и меньших усилий по обслуживанию, если таблица получает новый столбец или столбец получает переименован. (Обновление многочисленный SELECT, INSERTи UPDATEзапросы против обновления отображения конфигурации и , возможно , рефакторинга бизнес - классы и DTOs.)

Кроме того, при использовании NHibernate вы можете столкнуться с непредвиденными проблемами, если не очень хорошо знаете фреймворк. Это может быть, например, доверие к Table.hbm.xml, где вы устанавливаете длину строки для автоматической проверки. Однако я также могу представить себе подобные ошибки в «простом» уровне доступа к данным на основе запросов SqlConnection.

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

(Я должен, вероятно, добавить, что я думаю, что это похоже на первое «большое» приложение на основе .NET / C #, которое потребует командной работы. Хорошие практики, которые считаются вполне нормальными в Stack Overflow, такие как модульное тестирование или непрерывная интеграция, не являются -существует здесь до сих пор.)

Ответы:


26

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

Почему ORM усложняет отладку? Вы получите один и тот же результат независимо от того, исходит ли он из сохраненной процедуры или из ORM.

Я полагаю, что единственный реальный ущерб, который я могу придумать для ORM, - это то, что модель безопасности немного менее гибкая.

РЕДАКТИРОВАТЬ: Я просто перечитал ваш вопрос, и похоже, что они копируют и вставляют запросы во встроенный sql. Это делает модель безопасности такой же, как ORM, поэтому у этого подхода не будет абсолютно никаких преимуществ перед ORM. Если они используют непараметризованные запросы, это может представлять угрозу безопасности.


1
Сложнее отлаживать: если генерируется исключение, вам, вероятно, нужно знать структуру вместо того, чтобы знать исключения SqlConnection и т. Д.
завис,

4
Разве исключение sql не будет частью исключения ORM?
Джованни Гальбо,

1
Да, большинство оборачивает исключение, так что вы все равно сможете получить исходное исключение через .inner
mattlant

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

Как насчет того, чтобы структура вашей базы данных сильно отличалась от ваших бизнес-объектов. Разве это не превратило бы все это в накладные расходы? программирование сопоставлений с помощью xml, вместо того, чтобы просто предоставлять необходимые функции на стороне db с помощью SP ...?
Ури Абрамсон

58

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

Например, я работаю в крупном финансовом учреждении, и мы должны соблюдать множество правил безопасности. Чтобы соответствовать установленным для нас правилам и положениям, единственный способ пройти аудит - это сохранить доступ к данным в рамках хранимых процедур. Некоторые могут сказать, что это просто глупо, но, честно говоря, это не так. Использование инструмента ORM означает, что инструмент / разработчик может вставлять, выбирать, обновлять или удалять все, что он или она хочет. Хранимые процедуры обеспечивают гораздо большую безопасность, особенно в средах при работе с данными клиентов. Я думаю, это главная причина задуматься. Безопасность.


25
Я думаю, что это скорее ограничение текущих библиотек orm, которые не поддерживают хранимые процедуры, чем фундаментальное ограничение или отображение. Существуют orm, которые могут обрабатывать хранимые процессы и представления, и есть что сказать о решении orm + хранимых процедур.
Мендельт,

4
В случае хорошего ORM вы все равно сможете заставить его использовать SP (конечно, это
уменьшает

3
Тема, почему SP на самом деле не обеспечивают большей безопасности, чем ORM, хорошо проработана. Вот только одна статья, которая хорошо ее освещает
Тим Скотт,

1
Что ж, в Sql Server 2005 нельзя просто назначить схему в базе данных только для уровня ORM? Или этого мало? Если приложения являются веб-приложениями, то одно дело - подключение к базе данных. Затем безопасность оставалась на уровне приложений.
Мин

2
Конечно, вы можете ограничить то, что пользователь может делать с ORM. Вы просто устанавливаете параметры безопасности пользователей в SQL и даете им привилегии вставлять / обновлять / удалять то, что вы хотите. Это будет то же самое, что установить привилегии безопасности для хранимых процедур,
Доктор Джонс,

55

Сладкое место ORM

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

У вас вполне может быть несколько запросов, которые лучше выполнять вручную. В этом случае не бойтесь написать несколько хранимых процедур, чтобы справиться с этим. Даже если вы намереваетесь перенести свое приложение на несколько платформ СУБД, код, зависящий от базы данных, будет в меньшинстве. Принимая во внимание, что вам нужно будет протестировать свое приложение на любой платформе, на которой вы собираетесь его поддерживать, небольшие дополнительные усилия по переносу некоторых хранимых процедур не сильно повлияют на вашу совокупную стоимость владения. В первом приближении 98% переносимость ничем не хуже, чем 100% переносимости, и намного лучше, чем запутанные или плохо работающие решения для обхода ограничений ORM.

Я видел, как первый подход хорошо работает в очень большом (100 человеко-лет) проекте J2EE.

Если ORM может не подойти

В других случаях могут быть подходы, которые подходят приложению лучше, чем ORM. В книге Фаулера « Шаблоны архитектуры корпоративных приложений» есть раздел, посвященный шаблонам доступа к данным, который неплохо справляется с каталогизацией различных подходов к этому. Я видел несколько примеров ситуаций, когда ORM может быть неприменим:

  • В приложении с обширной устаревшей кодовой базой хранимых процедур вы можете захотеть использовать функционально ориентированный (не путать с функциональными языками) уровень доступа к данным, чтобы обернуть существующие sprocs. Это повторно использует существующий (и, следовательно, протестированный и отлаженный) уровень доступа к данным и структуру базы данных, что часто представляет собой довольно существенные усилия по разработке и тестированию и позволяет избежать необходимости переноса данных в новую модель базы данных. Часто это хороший способ обернуть слои Java вокруг устаревших баз кода PL / SQL или перенастроить полнофункциональные клиентские приложения VB, Powerbuilder или Delphi с веб-интерфейсами.

  • Вариант - это когда вы наследуете модель данных, которая не обязательно хорошо подходит для сопоставления OR. Если (например) вы пишете интерфейс, который заполняет или извлекает данные из внешнего интерфейса, вам может быть лучше работать напрямую с базой данных.

  • Финансовые приложения или другие типы систем, в которых важна межсистемная целостность данных, особенно если вы используете сложные распределенные транзакции с двухфазной фиксацией. Возможно, вам придется управлять своими транзакциями лучше, чем это может поддерживать ORM.

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

  • Ситуации, когда вы используете существующий механизм доступа к данным, такой как ADO.Net, который «достаточно хорош» и хорошо работает с платформой, приносят большую пользу, чем ORM.

  • Иногда данные - это просто данные - это может быть случай (например), что ваше приложение работает с «транзакциями», а не с «объектами», и это разумное представление о предметной области. Примером этого может быть финансовый пакет, в котором у вас есть транзакции с настраиваемыми полями анализа. Хотя само приложение может быть построено на платформе OO, оно не привязано к одной модели бизнес-области и может не знать гораздо больше, чем коды GL, учетные записи, типы документов и полдюжины полей анализа. В этом случае приложение не знает о модели бизнес-домена как таковой, а объектная модель (за пределами самой структуры реестра) не имеет отношения к приложению.


«или другие типы систем, в которых важна целостность данных» ... Помимо социальных сайтов, если целостность ваших данных не важна, зачем вообще создавать систему?
ObiWanKenobi

3
Этот момент конкретно относится к распределенным транзакциям, в которых несколько систем должны гарантировать синхронную фиксацию или откат либо вне очереди сообщений. Не все эти системы будут созданы для вас и, следовательно, не обязательно будут поддерживать ORM. Возможно, вам придется явно управлять транзакциями, для чего может потребоваться использование Takelit более низкого уровня, чем ORM.
ConcernedOfTunbridgeWells

1
Я знаю, что прошло больше года, но +1 для вас за упоминание того факта, что иногда данные - это просто данные.
luis.espinal

37

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

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

  1. Тестирование вашего кода
  2. Поддержание вашего кода

Решения для них:

  1. Сделайте свой код тестируемым (используя принципы SOLID )
  2. Напишите автоматизированные тесты для максимально возможной части кода
  3. Как можно чаще запускайте автоматические тесты

Что касается вашего вопроса, то два перечисленных вами возражения больше похожи на невежество, чем на что-либо еще.

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

Я бы не стал использовать ORM по двум причинам:

  1. Это категорически запрещено политикой компании (в таком случае я бы поработал в другом месте)
  2. Проект чрезвычайно интенсивной обработкой данных и с использованием поставщика конкретных решений (например , BulkInsert) имеет больше смысла.

Обычные возражения против ORM (в частности, NHibernate):

  1. Скорость

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

  2. Сложность

    Что касается сложности, использование ORM означает меньше кода, что обычно означает меньшую сложность. Многие люди, использующие рукописный (или сгенерированный код) доступ к данным, обнаруживают, что пишут свою собственную структуру на основе «низкоуровневых» библиотек доступа к данным (например, написание вспомогательных методов для ADO.Net). Это приравнивается к большей сложности, и, что еще хуже, они редко хорошо документированы или хорошо протестированы.
    Если вы смотрите конкретно на NHibernate, то такие инструменты, как Fluent NHibernate и Linq To NHibernate, также смягчают кривую обучения.

Во всей дискуссии об ORM меня беспокоит то, что те же люди, которые утверждают, что использование ORM будет слишком сложным / медленным или чем-то еще, - это те же самые люди, которые более чем счастливы использовать Linq To Sql или типизированные наборы данных. Хотя Linq To Sql - большой шаг в правильном направлении, он все еще на световые годы отстает от некоторых ORM с открытым исходным кодом. Тем не менее, фреймворки для типизированных наборов данных и Linq To Sql по-прежнему чрезвычайно сложны, и использовать их, чтобы зайти слишком далеко от (Table = Class) + (basic CRUD), глупо сложно.

Мой совет: если в конце дня вы не можете получить ORM, убедитесь, что ваш доступ к данным отделен от остальной части кода, и что вы следуете советам Банды четырех по кодированию, чтобы интерфейс. Кроме того, получите фреймворк Dependancy Injection для подключения.

(Как тебе напыщенная речь?)


33

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

Одна из сильных сторон Hibernate заключается в том, что вы можете сказать что-то только 3 раза: каждое свойство упоминается в классе, файле .hbm.xml и базе данных. В SQL-запросах ваши свойства находятся в классе, базе данных, операторах select, операторах вставки, операторах обновления, операторах удаления и всем коде маршаллинга и демаршалинга, поддерживающем ваши запросы SQL! Это может быстро испортиться. С другой стороны, вы знаете, как это работает. Вы можете отладить это. Все в порядке в вашем собственном слое персистентности, а не в недрах сторонних инструментов.

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

РЕДАКТИРОВАТЬ: вы можете изучить iBatis.NET, если они не собираются отказываться от NHibernate и хотят контролировать свои SQL-запросы.

РЕДАКТИРОВАТЬ 2: Вот большой красный флаг: «Хорошие практики, которые считаются вполне нормальными для Stack Overflow, такие как модульное тестирование или непрерывная интеграция, здесь до сих пор не существуют». Итак, эти «опытные» разработчики, какой у них опыт в разработке? Их безопасность работы? Похоже, вы можете быть среди людей, которые не особенно заинтересованы в этой области, поэтому не позволяйте им убивать ваш интерес. Вам нужно соблюдать баланс. Устраивать драку.


3
Повторение больше не соответствует действительности. Если вы используете аннотации JPA, вам нужно указать их только один раз. Hibernate даже создаст для вас операторы create вашей базы данных, хотя это наиболее полезно для определения правильности вашего сопоставления.
Джонатан-Стаффорд

Хорошее взвешенное обсуждение вопросов. Мой опыт работы с фреймворком Entity полностью соответствует вашему описанию «тратить часы, пытаясь уговорить ваш чертов инструмент», и «трудно убедить людей, которых там не было». Было очевидно, что это было быстрее написать, но это огромная трата времени, чтобы заставить работать действительно хорошо.

2
Прошло 8 лет, но это все еще правда: «Это может быть очень неприятно, когда вы знаете, что можете исправить SQL за считанные минуты, но вместо этого вы тратите часы, пытаясь уговорить свой опасный инструмент сгенерировать разумный SQL».
Руслан Стельмаченко

13

Я работал над одним проектом, в котором отказ от ORM был очень успешным. Это был проект,

  1. Должен быть горизонтально масштабирован с самого начала
  2. Надо было быстро развиваться
  3. Имел относительно простую модель предметной области

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

Итак, в 90% проектов, над которыми я работал, ORM оказал неоценимую помощь. Но есть некоторые очень специфические обстоятельства, при которых я считаю, что лучше не использовать ORM.


Вы дали несколько хороших аргументов против использования ORM в некоторых конкретных случаях. Однако этот проект относится к тем 90%, где ORM может помочь снизить затраты на разработку и сопровождение.
Hangy

Полностью согласен - извините, что не ответил прямо на ваш вопрос! Я считаю, что конкретные причины, которые вы упомянули, совершенно неверны :)
Майк,

Горизонтальное масштабирование NHibernate: blechie.com/WPierce/archive/2008/06/08/… , darioquintana.com.ar/blogging/?p=25
Маурисио Шеффер

11

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

Я обнаружил, что при проектировании систем, которые предъявляют высокие требования к производительности, мне часто приходится искать способы сделать систему более производительной. Часто я получаю решение с тяжелым профилем производительности записи (это означает, что мы пишем данные намного больше, чем читаем данные). В этих случаях я хочу воспользоваться возможностями, которые предлагает мне платформа баз данных, чтобы достичь наших целей по производительности (это OLTP, а не OLAP). Итак, если я использую SQL Server и знаю, что мне нужно написать много данных, почему бы мне не использовать массовую вставку ... ну, как вы, возможно, уже заметили, большинство ORMS (я не знаю, даже один из них) не имеет возможности воспользоваться преимуществами конкретных платформ, такими как объемная вставка.

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


9

Когда нужно обновить 50000000 записей. Установите флаг или что-то еще.

Попробуйте сделать это с помощью ORM без вызова хранимой процедуры или собственных команд SQL.

Обновление 1: попробуйте также получить одну запись с несколькими полями. (Когда у вас очень "широкий" стол). Или скалярный результат. ORM тоже отстой.

ОБНОВЛЕНИЕ 2 : похоже, что бета-версия EF 5.0 обещает пакетные обновления, но это очень горячие новости (2012, январь)



9

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

Помимо функций:

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

Чтобы представить аргументацию в некоторой перспективе, рассмотрим преимущества использования ADO.NET по сравнению с написанием кода для самостоятельного анализа потока табличных данных.

Я видел, как незнание того, как использовать ORM, оправдывает презрение разработчика к ORM. Например: жадная загрузка (я заметил, что вы не упомянули). Представьте, что вы хотите получить клиента и все его заказы, а для них - все детали заказа. Если вы полагаетесь только на ленивую загрузку, вы откажетесь от своего опыта работы с ORM с мнением: «ORM работают медленно». Если вы научитесь использовать нетерпеливую загрузку, вы сделаете за 2 минуты с 5 строками кода то, что вашим коллегам понадобится полдня на реализацию: один запрос к базе данных и привязка результатов к иерархии объектов. Другой пример - необходимость вручную писать SQL-запросы для реализации разбиения на страницы.

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

Не позволяйте опыту старших сотрудников увлечь вас в направлении, противоположном эволюции информатики. Я профессионально развиваюсь 23 года, и одна из констант - пренебрежение старым к новому. ORM для SQL так же, как язык C для сборки, и вы можете поспорить, что эквиваленты C ++ и C # уже в пути. Одна строка кода новой школы равна 20 строкам старой школы.


8

Я думаю, что, возможно, когда вы работаете над более крупными системами, вы можете использовать инструмент генератора кода, такой как CodeSmith, вместо ORM ... Я недавно нашел это: Cooperator Framework, который генерирует хранимые процедуры SQL Server, а также генерирует ваши бизнес-объекты, картографы, шлюзы, lazyload и все такое прочее на C # ... посмотрите ... это написала команда здесь, в Аргентине ...

Я думаю, что это что-то среднее между кодированием всего уровня доступа к данным и использованием ORM ...


6

Лично я (до недавнего времени) выступал против использования ORM и привык писать слой доступа к данным, инкапсулирующий все команды SQL. Основным возражением против ORM было то, что я не доверял реализации ORM в написании именно правильного SQL. И, судя по ORM, которые я видел (в основном библиотеки PHP), я думаю, что был полностью прав.

Сейчас большая часть моей веб-разработки использует Django, и я нашел, что включенный ORM действительно удобен, и поскольку модель данных сначала выражается в их терминах, а только потом в SQL, она отлично работает для моих нужд. Я уверен, что перерасти это будет несложно и нужно дополнить написанным вручную SQL; но для CRUD доступа более чем достаточно.

Я не знаю насчет NHibernate; но я думаю, он также «достаточно хорош» для большей части того, что вам нужно. Но если другие кодировщики ему не доверяют; он будет главным подозреваемым в каждой ошибке, связанной с данными, что сделает проверку более утомительной.

Вы можете попытаться внедрить его постепенно на своем рабочем месте, сосредоточив внимание сначала на небольших «очевидных» приложениях, таких как простой доступ к данным. Через некоторое время он может быть использован на прототипах, и его нельзя будет заменить ...


5

Если это база данных OLAP (например, статические данные только для чтения, используемые для отчетов / аналитики и т. Д.), То реализация структуры ORM не подходит. Вместо этого было бы предпочтительнее использовать собственные функции доступа к данным базы данных, такие как хранимые процедуры. ORM лучше подходят для транзакционных (OLTP) систем.


Вы уверены, что? OLTP так же не подходят для ORM, как и OLAP (я имею в виду, в зависимости от сложности). Между этими двумя крайностями существует широкий спектр приложений, в которых ORM хорошо справляется. Но для OLAP и OLTP они могут стать помехой.
luis.espinal

4

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

Я был профессиональным разработчиком в течение 10 лет, руководил несколькими очень успешными проектами на миллион с лишним долларов и ни разу не написал приложение, которое требовало переключения на любую базу данных. Зачем вам вообще нужно, чтобы это делал клиент? Тщательно спланируйте, выберите правильную базу данных для того, что вам нужно, и придерживайтесь ее. Лично SQL Server мог делать все, что мне когда-либо требовалось. Это просто и отлично работает. Есть даже бесплатная версия, которая поддерживает до 10 ГБ данных. Да, и с .NET он отлично работает.

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

Честно говоря, я думаю, что у ORM есть одно реальное применение: если вы создаете приложение вроде SAP, которому действительно нужна возможность работать в нескольких базах данных. В противном случае, как поставщик решения, я говорю своим клиентам, что это приложение предназначено для работы в этой базе данных, и именно так оно и есть. Еще раз, спустя 10 лет и бесчисленное количество приложений, это никогда не было проблемой.

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


2
Я действительно не понимаю, почему этот ответ отклонен. Сохранение простоты за счет использования всего, что может предложить ваша среда, - отличная практика. Как опытный гуру чистого кода, я считаю, что orm трудно читать и, следовательно, трудно поддерживать. Вы не знаете, какие именно запросы выполняются, когда у вас есть сложные отношения в вашем приложении (что в конечном итоге и произойдет). Отладить такую ​​неразбериху в долгосрочной перспективе становится невозможно. Я говорю: делайте это просто, не используйте ORM.
Дэвид

Это смешно. Я работаю разработчиком 24 года и никогда не участвовал в проектах, где можно было бы поддерживать только одного поставщика СУБД. Каждый проект ТРЕБУЕТ, чтобы мы поддерживали нескольких поставщиков СУБД, потому что нам нужно было быть достаточно гибкими, чтобы работать с клиентами, которые ТРЕБУЮТ Oracle, и работать с другими клиентами, которые ТРЕБУЮТ SQL Server. Если вы создаете приложение «дымохода» в вакууме, то да, вы можете просто диктовать СУБД. Но я никогда не участвовал в проектах, где это было приемлемо.
deltamind106,

У меня было много приложений, в которых я могу диктовать СУБД, главным образом потому, что в большом количестве внутренних приложений и клиентов, просматривающих «наши» данные. Я также являюсь разработчиком 24 года.
Джеффкенн

3

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

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


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

3

Есть два аспекта ORM, которые вызывают беспокойство. Во-первых, это код, написанный кем-то другим, иногда с закрытым исходным кодом, иногда с открытым исходным кодом, но огромным по объему. Во-вторых, они копируют данные.

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

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


2
Умм ... если вы используете, скажем, .NET, вы полагаетесь на их код (который вы не можете изменить). Я не понимаю, что это более нормально, чем, например, полагаться на код NHibernate. Относительно смешно быть параноиком библиотек, которые вы не писали сами. Похоже, вы страдаете от NIH
Джейсон Бантинг

компиляторы и виртуальные машины являются относительно стабильной частью CS, и их несложно проверить с помощью тестов. ORM-дизайн может быть «немного неправильным» или неполной документацией. все это затрудняет доверие к чему-то столь простому, как компилятор.
Хавьер,

1
Это предупреждение ... а не заявление о неиспользовании. И это только одно предупреждение из трех.
dacracot

1
@dacracot: Вы все время полагаетесь на множество стороннего кода ... начиная с вашей операционной системы, поэтому я не думаю, что ваша точка зрения верна. Второй момент можно смягчить с помощью оптимистической блокировки, более того, он не имеет ничего общего с двухфазной фиксацией.
Adam Byrtek 02

1
dacracot уместен, если говорить о некоторых из менее зрелых ORM. Я уверен, что есть такие каменные шары, но большинство из них будут несовершенными, и это может быть проблемой в некоторых (не в большинстве) средах. Что касается двухэтапной фиксации ... есть способы смоделировать саму транзакцию БД в коде, но зачем добавлять уровень косвенного обращения, который не обеспечивает никакой абстракции?
Том


3

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

Также с ORM люди легко склонны злоупотреблять существующими сопоставлениями / моделями, что приводит к тому, что существует объект с множеством атрибутов, которые не инициализированы. Поэтому после запроса внутри транзакции Hibernate выполняет дополнительную выборку данных, что может привести к замедлению. К сожалению, объект модели hibernate иногда просачивается на уровень архитектуры представления, и тогда мы видим LazyInitializationExceptions.

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


Hibernate не поддерживает UNION? Это довольно фундаментальная часть теории множеств! Я полагаю, это просто указывает на другой взгляд на проблему.
Том

3

Чтобы не быть ответом как таковым, я хочу перефразировать цитату, которую слышал недавно. «Хорошая ORM похожа на Йети: все говорят об одном, но никто этого не видит».

Всякий раз, когда я беру ORM, я обычно сталкиваюсь с проблемами / ограничениями этого ORM. В конце концов, да, он делает то, что я хочу, и это было написано где-то в этой паршивой документации, но я теряю еще один час, которого никогда не получу. Любой, кто использовал nhibernate, а затем бегло nhibernate на postgresql, поймет, через что я прошел. Постоянное ощущение «этот код мне не подвластно» - отстой.

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


Спустя много лет (и ORM) я решил использовать Postgresql / EntityFramework с Code First Migrations. Это позволяет мне включить сохранение данных с помощью классов, которые я написал, и я наконец могу синхронизировать / редактировать изменения моей базы данных, интегрированные в мою производственную среду. Это почти прозрачный уровень доступа к данным, который экономит много времени во время разработки, но в то же время я могу углубиться и написать сложные запросы, когда захочу. Конечно, это решение dotnet, но я наконец смирился с доступом к базе данных.
Detay 07

2

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

В пользу № 1 нет аргументов, поскольку копирование и вставка запросов и жесткое кодирование в тексте не дает гибкости, а для № 2 большинство команд переносят исходное исключение, позволяют отслеживать сгенерированные запросы и т. Д., Поэтому отладка также не является ракетной наукой.

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

Написание собственного фреймворка может быть трудоемким, и часто что-то упускается.

РЕДАКТИРОВАТЬ: Я хотел сделать еще одно замечание. Если ваша компания примет стратегию ORM, это еще больше повысит ее ценность, так как вы будете разрабатывать руководящие принципы и практики для использования и внедрения, и каждый будет дальше расширять свои знания о выбранной структуре, смягчая одну из поднятых вами проблем. Кроме того, вы узнаете, что работает, а что нет, когда возникают ситуации, и в конечном итоге это сэкономит много времени и усилий.


1

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

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

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

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

В противном случае, к черту ORM. Сейчас я считаю их в основном модой.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.