2010-07-26 2 views
3

На работе мы только что обновили VS2005 до 2010 года. К этому моменту мы использовали только sprocs (я думаю, по привычке больше всего на свете). Я играю с Linq (очень простые учебники - ничего серьезного). Как мой первый опыт работы с ORM, мне это нравится.Linq vs MS Enterprise Library DAAB

Кроме того, я недавно познакомился с блоками Enterprise Library. Вообще говоря, будет ли проект использовать либо ORM, либо DAAB, или потенциально может использовать проект для обоих? Это зависит от ситуации или просто от предпочтения? Есть ли случаи, когда один вариант лучше другого?

Спасибо.

ответ

1

Один или другой ... Я не использовал DAAB через некоторое время, но LINQ to SQL или ADO.NET EF использует конструктор для генерации классов кода, представляющих базу данных, где DAAB построен на ADO .NET (DataSet и т. Д.).

Я люблю LINQ, прост в использовании, вы можете использовать хранимые процедуры просто для получения ваших данных или построить запрос LINQ для вывода данных (запрос LINQ-кода преобразуется в запрос базы данных).

Поэтому я предпочитаю LINQ; Если вы используете DAAB, я бы рекомендовал использовать инструмент code-gen.

HTH.

1

DAAB тесно связан с более старым способом доступа к базе данных (думаю, DataSets), в то время как современные ORM, такие как Linq, больше касаются строго типизированных объектов, сгенерированных из схемы базы данных.

Я предлагаю использовать DAAB только в том случае, если вам нужен нейтралитет базы данных (IIRC он хорошо подходит для использования с различными типами СУБД), и если вы хотите избежать инструментов, которые в значительной степени зависят от магии времени компиляции.

ORM обычно хороши в доставке ценности в виде простоты использования и поддержки инструмента. Однако они часто сталкиваются с «несоответствием объектно-реляционного импеданса», когда объекты выглядят и ведут себя как стандартные объекты на поверхности, но имеют далеко идущие требования к их использованию из-за того, что они абстрагируют СУРБД, которая не является по-настоящему совместимы с объектно-ориентированными вычислениями. Ваш код должен «знать», как использовать их, в противном случае сталкиваются с ловушками, которые вы не можете поймать во время компиляции.

Лично я бы избегал DAAB. Помимо нескольких ярких примеров (Unity!) EL довольно тяжеловес и требует много работы для понимания и использования должным образом. Его часто был установленный на тросах отбойный молоток, где было бы долото. Большинство ORM довольно чертовски хороши, недостатки в стороне. Linq to Sql является сплошным, и EF4 добирается туда. Существуют также альтернативы с открытым исходным кодом, такие как nHibernate, которые также обеспечивают хорошее значение для кривой обучения.

Если бы я завтра начал новый проект, я бы использовал недавно выпущенный EF4 code-first bits. Я думаю, что это главным образом потому, что я - обжора для наказания; EF4 была болью в моей заднице ...

2

Мы точно в том же месте, используя DAAB от 2.0 до 4.1. FWIW это наше мышление (мы на самом деле Pro ОРМ):

Существует компромисс между:

  • повышения производительности, что ОРМ с возможностями генерации кода дает (в частности, не имея рук кода SProcs и Объекты)
  • улучшенная гибкость, которую LINQ дает поЛегкая и ленивая загрузка, выборка только требуемых столбцов (узость запроса позволяет лучше ударять по индексам NC и Covering и т. Д.)
  • Насколько нам известно, LINQ использует параметризованные запросы и, следовательно, производительность w.r.t. кэш-план и не восприимчив к инъекциям SQL http://msdn.microsoft.com/en-us/library/bb386929.aspx

Однако, на нижней стороне

  • Потеря контроля над субъектами - они не обязательно ПОКО (для LINQ2SQL) и хотя EF4 позволяет ваш собственные POCO, и ленивая загрузка по-прежнему достижима с помощью прокси.
  • Отсутствие контроля/детерминизм в запросах, которые могли быть выполнены по отношению к БД, а это означает, что тестирование покрытия от БД является потенциальной проблемой (в то время как относительно просто определить стратегию индексирования для SPROC)
  • Если вы не будете осторожны, обновление графов сущностей может иметь непреднамеренное «глубинное» следствие. Linq2SQL может действительно сделать с аналогией «SavesWith» в жадная загрузка «LoadsWith»

В целом, мы довольны ОРМ в течение примерно 80% наших таблиц/сущностей, но будет выглядеть на пользовательские работы действительно чувствительный, специфичный для производительности материал.

HTH

Смежные вопросы