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

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

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

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

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

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

Джерри

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

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

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

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

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

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

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

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

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

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

on an on

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

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

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

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

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

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

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

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

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

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