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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Сделайте свой код тестируемым (используя принципы ТВЕРДЫЙ)
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 для подключения.

(Как тебе такая тирада?)

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

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

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

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

/ Асгер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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