Есть ли веские причины не использовать ОРМ?

Ответ 1

В последние годы произошел взрыв с ОРМ, и ваши более опытные сотрудники все еще могут думать о "менталитете каждого вызова базы данных с помощью хранимой процедуры".

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

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

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

Ответ 2

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

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

Ответ 3

Сладкое пятно ОРМ

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

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

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

Если ORM не может быть наилучшим образом

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

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

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

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

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

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

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

Ответ 4

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

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

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

Решениями для них являются:

• Сделайте свой код поддающимся проверке (используя SOLID Чада Мейера)
• Написать автоматические тесты для максимально возможного количества кода
• Запускайте автоматические тесты как можно чаще

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

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

Есть две причины, по которым я не использовал ORM:

• Категорически запрещается политика компании (в этом случае я бы пошел работать где-то еще)
• Проект чрезвычайно интенсивный, и использование решений, специфичных для конкретного поставщика (например, BulkInsert) имеет больше смысла.

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

• Скорость

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

• Сложность

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

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

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

(Как это для разговора?)

Ответ 5

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

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

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

EDIT: вы можете захотеть заглянуть в iBatis.NET, если они не собираются обходить NHibernate, и они хотят контролировать свои SQL-запросы.

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

Ответ 6

Я работал над одним проектом, где не было использования ORM. Это был проект, который

• Должно быть горизонтально масштабировано с самого начала
• Необходимо было быстро разработать
• Если бы была относительно простая модель домена

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

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

Ответ 7

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

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

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

Ответ 8

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

Особенности в стороне:

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

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

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

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

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

Ответ 9

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

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

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

ОБНОВЛЕНИЕ 2. Кажется, что пакет обновления EF 5.0 beta promises, но это очень жаркие новости (2012, январь)

Ответ 10

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

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

Ответ 11

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

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

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

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

Ответ 12

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

Ответ 13

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

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

Ответ 14

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

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

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

Ответ 15

Я предлагаю это чтение для списка недостатков ORM.

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Для себя, я нашел, что ORM очень полезны для большинства приложений, которые я написал!

/Asger

Ответ 16

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

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

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

Ответ 17

Чтобы не быть ответом как таковым, я хочу перефразировать цитату, которую я недавно слышал. "Хороший ОРМ подобен йети, все говорят об одном, но никто его не видит".

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

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

Ответ 18

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

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

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

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

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

Ответ 19

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

Нет аргументов для # 1, поскольку копирование и вставка запросов и hardcoding в тексте не дают никакой гибкости, а для # 2 большинство orm будут обматывать исходное исключение, позволят трассировать генерируемые запросы и т.д., поэтому отладка не является ракетой.

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

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

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

Ответ 20

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

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

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

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

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