Подтвердить что ты не робот

ORM vs Handcoded Data Access Layer

Мне немного страшно задавать этот вопрос, так как он может начать религиозную войну, поэтому я хочу быть предельно ясным в том, что я ищу. Я ищу причину (причины), почему вы или подпрыгнули так или иначе, а также элементы, которые нужно добавить в мои списки. Я ищу большой билет, большие вещи. Кроме того, элементы, относящиеся к продукту, возможно, если они действительно актуальны. На данный момент я пытаюсь оценить 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-инъекций. Любые комментарии по этому поводу?

4b9b3361

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

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

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

Ответ 3

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

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

EDIT: в отношении атак SQL-инъекций: недавняя система, которую я разработал с использованием этой ORM, была широко проверена и абсолютно никакой инъекции не было разрешено. Причина проста: он генерирует SQL "на лету" и всегда использует параметры, без конкатенации строк.

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

Я нахожу их банкой червей.

Ответ 8

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

Ответ 9

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

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

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

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

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

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

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

Ответ 10

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

Ответ 11

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

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

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

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

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

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

Ответ 12

Вам не нужно оставлять свои SPROC или обработанные вручную SQL с хорошим ORM, например nHibernate.

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

Ответ 13

Я использовал реализацию Castle Project Active Record с NHibernate для личного проекта. Проект никогда не был развернут, частично из-за моей неспособности работать с выбором ORM, который я сделал.

Причина, по которой я решил использовать ORM, состояла в том, что я хотел иметь возможность переключаться с SQL Server на MYSQL без изменения кода. В реальных проектах решение использовать SQL-сервер уже сделано для меня, и проще просто написать datalayers в традиционном 3-уровневом способе, когда вы знаете, что база данных не изменится. Но для личных проектов я использую общий хостинг, а MySQL - более дешевое решение.

Причина, по которой я пошла с замком, была потому, что она была очень проста в использовании. С плагином activewriter для визуальной студии я смог сгенерировать свои классы и базу данных с помощью конструктора (вроде как конструктор linq to SQL), и, похоже, он хорошо сочетался с моей ментальной моделью того, как ORM должен диктовать вашу архитектуру приложения.

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

Итак, я использую ORM, я сохранил много работы заранее, но я столкнулся с стеной, когда попытался исправить проблему с фреймворком, генерирующим слишком много SQL. (На котором я все еще медленно работаю).

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

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

Ответ 14

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

Ответ 15

Хорошо, это было для PHP-приложения, а не для .NET, но я думаю, что те же качества важны.

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

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

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

Ответ 16

Я был ОЧЕНЬ успешным, просто используя DataSets в .Net. У нас есть конечная точка SOAP, которая сначала проверит ввод с помощью .XSD. Затем вы можете использовать механизм правил для проверки. Тогда...

Если запрос заключается в вставке данных:

  • Используйте GetXml() в DataSet для преобразования в XML.
  • Отправьте XML в sproc, который использует OPENXML в SQL Server.

Если запрос заключается в выборе данных:

  • Напишите sproc для вывода данных с помощью нескольких инструкций SELECT.
  • Загрузите эти данные в DataSet (обязательно создайте "вложенные" отношения там, где это необходимо).
  • Используйте GetXml() в DataSet для скрытого использования XML, используемого в SOAP.

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