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

Question

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

Answer 1

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

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

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

Answer 2

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

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

Jerry

Answer 3

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

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

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

Answer 4

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

Теперь минусы этого подхода обычно заключаются в непонимании того, как все работает на очень низком уровне. Наиболее классическая проблема - «ВЫБЕРИТЕ N + 1» ( ссылка ).

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

Answer 5

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

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

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

вкл на

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

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

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

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

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

Answer 6

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

Answer 7

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

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

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

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

Answer 8

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