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

Во время учебы я использовал 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, такие как модульное тестирование или непрерывная интеграция, не являются -существует здесь до сих пор.)

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

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

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

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

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

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

Сладкое место 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, учетные записи, типы документов и полдюжины полей анализа. В этом случае приложение не знает о модели бизнес-домена как таковой, а объектная модель (за пределами самой структуры реестра) не имеет отношения к приложению.

Во-первых, использование 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 для подключения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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