Картопостроители O/R - Хороший или плохой

This will seem like an unrelated answer at first, but: one of my side interests is WWII-era fighter planes. All of the combatant nations (US, Great Britain, Germany, USSR, Japan etc.) built a bunch of different fighters during the war. Some of them used radial engines (P47, Corsair, FW-190, Zero); some used inline liquid-cooled engines (Bf-109, Mustang, Yak-7, Spitfire); and some used two engines instead of one (P38, Do-335). Some used machine guns, some used cannons, and some used both. Some were even made out of plywood, if you can imagine.

In the end, they all went really really fast, and in the hands of a competent, experienced pilot, they would shoot your rookie ass down in a heartbeat. I don't imagine many pilots flew around thinking "oh, that idiot is flying something with a radial engine - I don't have to worry about him at all". Everyone understood that there were many different ways of achieving the ultimate goal, and each approach had its particular advantages and disadvantages, depending on the circumstances.

The debate between ORM and traditional data access is just like this, and it behooves any programmer to become competent with both approaches, and choose the option that is right for the job at hand.

I struggled with this decision for a long time. I think I was hesitant for two primary reasons. First, O/R mappers represented a lack of control over what was happening in a critical part of the app and, second, because so many times I've been disappointed by solutions that are awesome for the 90% case but miserable for the last 10%. Everything works for select * from authors, of course, but when you crank up the complexity and have a high-volume, critical system and your career is on the line, you feel you need to have complete control to tune every query pattern and byte over the wire. Most developers, including me, get frustrated the first time the tool fails us, and we cannot do what we need to do, or our need deviates from the established pattern supported by the tool. I'll probably get flamed for mentioning specific flaws in tools, so I'll leave it at that.

Fortunately, Anderson Imes finally convinced me to try CodeSmith with the netTiers template. (No, I don't work for them.) After more than a year using this, I can't believe we didn't do it sooner. My team uses Visual Studio DB Pro, and on every check-in our continuous integration build drops out a new set of data access layer assemblies. This handles all the common, low risk stuff automatically, yet we can still write custom sprocs for the tricky bits and have them included as methods on the generated classes, and we can customize the templates for the generated code as well. I highly recommend this approach. There may be other tools that allow this level of control as well, and there is a newer CodeSmith template called PLINQO that uses LINQ to SQL under the hood. We haven't that yet examined (haven't needed to), but this overall approach has a lot of merit.

Jerry

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

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

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

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

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

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

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

I first got into ORM mapping and Data Access Layers from reading Rockford Lhotka's book, C# business objects. He's spent years working on a framework for DAL's. While his framework out of the box is quite bloated and in some cases, overkill, he has some excellent ideas. I highly recommend the book for anyone looking at ORM mappers. I was influenced by his book enough to take away a lot of his ideas and build them into my own framework and code generation.

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

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

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

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

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

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

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

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