O/R Mappers - хорошо или плохо

Question

Я действительно разорван прямо между использованием карт памяти O/R или просто привязан к традиционному доступу к данным. По какой-то причине каждый раз, когда я вывожу карточек O/R, другие разработчики сжимаются и говорят о проблемах с производительностью или о том, как они вообще плохие. Что мне здесь не хватает? Я смотрю на LINQ to SQL и Microsoft Entity Framework. Есть ли какие-либо основания для любой из этих претензий? Какие вещи я должен скомпрометировать, если я хочу использовать O/R mapper. Благодарю.

Answer 1

Проблема, с которой я вижу много карточек ИЛИ, заключается в том, что вы получаете раздутые объекты домена, которые обычно связаны с остальной базой данных. Наши разработчики тоже с этим справляются :) Это просто сложнее переносить этот объект на другую технологию доступа к данным. Если вы используете L2S, вы можете взглянуть на сгенерированный код. Это похоже на полный беспорядок. NHibernate, вероятно, является одним из лучших в этом. Ваши объекты полностью не знают о вашем уровне доступа к данным, если вы правильно их проектируете.

Answer 2

Я впервые попал в картографирование ORM и слои доступа к данным от чтения книги Рокфорда Лхотки, бизнес-объектов C#. Он провел годы, работая над рамкой для DAL. В то время как его рамки из коробки очень раздуты, а в некоторых случаях, излишнем, у него есть отличные идеи. Я настоятельно рекомендую книгу для тех, кто смотрит на ORM-карт. Я был под влиянием его книги достаточно, чтобы забрать много его идей и построить их в свои рамки и генерации кода.

Answer 3

Сначала это будет несвязанный ответ, но: один из моих интересов - это истребители Второй мировой войны. Все боевые страны (США, Великобритания, Германия, СССР, Япония и т. Д.) Создали войну разных бойцов. Некоторые из них использовали радиальные двигатели (P47, Corsair, FW-190, Zero); некоторые используемые встроенные двигатели с жидкостным охлаждением (Bf-109, Mustang, Yak-7, Spitfire); и некоторые использовали два двигателя вместо одного (P38, Do-335). Некоторые использовали пулеметы, некоторые использовали пушки, а некоторые использовали оба. Некоторые даже были сделаны из фанеры, если вы можете себе представить.

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

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

Answer 4

Я долгое время боролся с этим решением. Думаю, я колебался по двум основным причинам. Во-первых, O/R-mappers представляли собой отсутствие контроля над тем, что происходило в критической части приложения, и, во-вторых, потому что столько раз я был разочарован решениями, которые являются удивительными для 90% -ного случая, но несчастны для последнего 10%. Конечно, все работает на выбор * от авторов, но когда вы справляетесь со сложностью и имеете высокую объемную критическую систему, и ваша карьера находится на линии, вы чувствуете, что вам нужно иметь полный контроль для настройки каждого шаблона запроса и байт над проводом. Большинство разработчиков, включая меня, расстраиваются при первом запуске инструмента, и мы не можем делать то, что нам нужно, или наша потребность отклоняется от установленного шаблона, поддерживаемого инструментом. Я, вероятно, буду пылать, чтобы упомянуть о некоторых недостатках в инструментах, поэтому я оставлю это на этом.

К счастью, Anderson Imes, наконец, убедил меня попробовать CodeSmith с netTiers template. (Нет, я не работаю для них.) Спустя более года, используя это, я не могу поверить, что мы этого не сделали раньше. Моя команда использует Visual Studio DB Pro, и при каждой проверке наша сборка непрерывной интеграции выдает новый набор сборок доступа к данным.Это автоматически обрабатывает все обычные материалы с низким уровнем риска, но мы все же можем писать собственные sprocs для сложных битов и включать их в качестве методов для сгенерированных классов, и мы также можем настроить шаблоны для сгенерированного кода. Я очень рекомендую этот подход. Могут быть и другие инструменты, которые позволяют этот уровень управления, а также новый шаблон CodeSmith, называемый PLINQO, который использует LINQ to SQL под капотом. Мы еще не изучили (не нужно), но этот общий подход имеет много преимуществ.

Jerry

Answer 5

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

Однако, возьмите LinqToSql - если вы уверены, что вам не нужно будет удаляться от SQL Server, тогда это решает множество общих проблем, наблюдаемых в устройствах ORM. Это позволяет вам легко добавлять хранимые процедуры (как статические методы), поэтому вы не ограничены только созданным SQL. Он использует отложенное выполнение, чтобы вы могли эффективно связывать запросы. Он использует частичные классы, чтобы вы могли легко добавлять пользовательскую логику к сгенерированным классам, не беспокоясь о том, что происходит, когда вы их повторно генерируете. Также нет ничего, что останавливало бы вас, используя LINQ для создания собственного абстрактного DAL - это просто ускоряет процесс. Главное, дело в том, что это облегчает скуку и время, необходимые для создания основного слоя CRUD.

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

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

Answer 6

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

В настоящее время недостатки такого подхода, как правило, заключаются в недостаточном понимании того, как все работает на очень низком уровне. Самая классическая проблема - «SELECT N + 1» (link).

Я работаю с NHibernate в течение 2,5 лет, и я до сих пор открывать что-то новое об этом почти ежедневно ...

Answer 7

Хорошо. В большинстве случаев.

Преимущества производительности использования ОРМ в большинстве случаев перевешивают потерю контроля над доступом к данным.

Существует не так много, кто бы избегал C#, чтобы программировать MSIL или Assembly, хотя это дало бы им больше контроля.

Answer 8

Это действительно зависит от ситуации.

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

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

на постоянной

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

• у нас было несколько запросов, которые были почти идентичны, и много раз, если была ошибка, только горстка будет исправлена ​​
• вместо кэширования общих табличных запросов, мы закончили бы чтение таблицы несколько раз.
• Мы повторяли себя на месте
• У нас было несколько уровней мастерства, поэтому некоторые запросы не были написаны наиболее эффективно.

После того, как я указал на это, они написали «DBO», потому что не хотели называть его ORM. Они решили написать один с нуля, вместо того, чтобы подстроить его.

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

У современных ORM есть много инструментов, которые помогут вам, например, сценарии миграции, множественные типы БД, доступ к одним и тем же объектам, чтобы вы могли использовать преимущества как NOSQL, так и SQL DB. Но вы должны выбрать правильный ORM для своего проекта, если вы собираетесь его использовать.