ORM против уровня доступа к данным с ручным кодированием

Question

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

Преимущества ORM

 - Quick to code and low maintenance (in some/most scenarios) 
 - Additional features for "free" (no developer effort)

Преимущества ручного кодирования

 - More Efficient (at runtime, maybe not at dev time?)
 - Less layers of complexity
 - Most ORMS seem to struggle with being retricted to sprocs only

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

Наверное, также стоит отметить, что я нахожусь в мире .Net

[править] (вопрос на Использование ORM или простого SQL? , кажется, отвечает на многие вопросы и усиливает точку зрения на производительность)

Итак, чтобы немного изменить мой вопрос

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

[Дальнейшее редактирование - теперь суть проблемы] Наличие веб-сайта, способного выполнить любой SQL для моей базы данных, пугает. Если весь доступ осуществляется через sprocs, моя база данных живет в хорошей, безопасной и удобной изоляции. Использование исключительно sprocs удаляет многие, если не все векторы атаки SQL-инъекций. Любые комментарии по этому поводу?

Answer 1

Первоначально мы писали приложение с использованием JPA с того самого дня, как мы начали его выпуск, мы сожалели об этом. Количество обращений к базе данных, сделанных ORM, было астрономическим, поэтому мы начали процесс переписывания приложения по частям, используя хороший старый JDBC с использованием вспомогательных классов JDBC Spring. Подводные камни при запуске с ORM заключаются в том, что мы потратили много времени на изучение JPA, и в конце дня мы должны заменить его на JDBC, чтобы наше приложение могло быть более масштабируемым без добавления трех других узлов в наш Oracle RAC. Таким образом, если вы уравновешиваете это, контроль и точность JDBC стоили дополнительных строк кода, которые вы должны написать. Кроме того, большинство людей не понимают, что SQL - это не то, что может быть сгенерировано и ожидается, что оно будет работать. Это то, что нужно написать и настроить, чтобы добиться максимальной производительности.

Answer 2

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

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

Мой друг работал с парнем, который разработал собственный инструмент ORM. У него была замечательная возможность локального кэширования всего, что вы, возможно, захотите получить из базы данных, путем обхода внешних ключей. Недостатком было то, что чтение одного столбца из одной строки в БД привело к превышению 11 000 операторов выбора.

Answer 3

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

Я вполне доволен этим и не буду использовать никакой другой подход.

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

Answer 4

Несколько недель назад я начал разработку нового проекта. У меня был полный контроль над инструментами, которые я мог использовать. Я начал с db40, потому что хотел полностью устранить этот вопрос; Я просто хотел сохранить мои объекты напрямую, забыть об ADO.NET или OR / M. Но у db40 были проблемы, поэтому я должен был отказаться от него.

Мой следующий выбор был ADO.NET, потому что я думал, что это будет быстро и легко. Но мне пришлось писать слишком много кода, использовать слишком много «строк SQL», и это была просто рутинная работа. Я имею в виду, что это была королевская PITA, и после написания двух репозиториев я захотел отрезать себе запястья.

Моим третьим выбором был NHibernate. У меня были предыдущие проблемы с NHibernate в ситуации, когда мне нужно было использовать отключенные объекты (так было и в этот раз, поэтому мне потребовалось три попытки добраться до него). Но это был NHibernate 1.2. На этот раз я получил бинарные файлы 2.0 и у меня не было проблем с обновлением отключенных объектов. Я также должен был написать гораздо меньше строк кода, и это было очень просто, когда мне нужно было рефакторинг, что, вероятно, было самым важным, поскольку мой дизайн быстро менялся.

Сейчас я продан на NHibernate. Похоже, что он также оптимизирован. Честно говоря, я не могу найти негатив на это. И нет хранимых процедур.

Я знаю, что это мой выбор в пользу OR / M, и я никогда больше не буду писать прямо на ADO.NET.

Answer 5

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

Я считаю их червячной банкой.

Answer 6

Вы пробовали рыжее? На этапе разработки он плавный и простой в использовании, а в режиме производства (замороженный) - быстрый. http://redbeanphp.com

Answer 7

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

Мой выбор - NHibernate. Я действительно новичок в этом прямо сейчас. Но мне нравится возможность использовать Fluent NHibernate или Castle ACtiveRecord. Похоже, именно здесь находится разум.

Но не уверен, что я буду делать в мире "все, что есть".

Answer 8

Мне пришлось переписать DAL производственного приложения, которое использовало объектную базу данных. Мы хотели поддерживать как объектную базу данных, так и базу данных sql. Некоторые функции, которые я действительно не хотел реализовывать самостоятельно, которые там, где уже присутствовали функции, были

• прозрачная отложенная загрузка с переопределением по запросу
• Идентификатор объекта (всегда получать одинаковые ссылки для одинаковых объектов)
• Вставка / Обновление дозирования
• Выбор дозирования (фьючерсы в NHibernate)
• Идентификатор поколения
• перевод API запросов в sql (критерии были идеальными из-за модульной природы API запросов)

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

• Автоматическое сопоставление классов (всего 3 страницы кода для генерации целых отображений)
• Поддержка LINQ (когда-нибудь пытался реализовать LINQ-провайдера самостоятельно?)
• расширенная регистрация бесплатно
• проще модульное тестирование с помощью памяти sqlite
• поддержка разных db-провайдеров
• Генерация схемы очень проста (не нужно поддерживать какие-либо сценарии генерации для разных провайдеров БД)
• оптимистичный параллелизм
• документация для N / Hibernate - отличный учебный ресурс по реляционным методикам

Я не могу себе представить, как написать более производительный SQL вручную, чем то, что генерирует NHibernate. Некоторые аргументы против:

• загрузка всего объекта, когда требуется всего несколько свойств -> всегда есть проецирование в DTO или в C # 3.0 на анонимные типы (SetProjection () / Select ())
• много выборок вместо объединений -> использование быстрой загрузки в случае необходимости (SetFetchMode () / Fetch ())
• улучшенный sql всегда более производительный, чем сгенерированный -> оптимизация архитектуры >> микрооптимизация, с ORM было намного проще реорганизовать архитектуру из-за меньшего количества кода и менее повторяющейся логики (попробуйте изменить что-то вроде один ко многим ко многим -в-многих в рукописном дал)

Answer 9

Прокомментируйте свой вопрос о Stored Proc. Независимо от того, как написана функциональность, DAL, ORM, хранимые процессы, будет задействован SQL. Если вы используете хранимые процедуры, вы пишете SQL внутри, и в него довольно легко встроить полезные абстракции. Если вы используете DAL, вы пишете SQL, но на практике это скорее будет неабстрагированный SQL с повышенной подверженностью внедрению. Если вы используете ORM, инструмент записывает SQL (за который вы, тем не менее, в конечном итоге несете ответственность - включая инъекцию). ИМХО, чем меньше движущихся частей (особенно тех, которые вы знаете и понимаете), тем лучше.

Answer 10

Я унаследовал веб-приложение, созданное с помощью NHib и MyGeneration, к сожалению, не получил репозиторий svn, и у меня больше нет исходных шаблонов (arrggg).

Сохраняли nhibernate для вещей создания / обновления / удаления, но интерфейс (только для чтения) был реализован несколько безрассудно и работает как 2-хногая собака, и теперь переписывается в простой старый ADO.NET, и идет в 10 раз быстрее.

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

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

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

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

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