В чем преимущества LINQ to SQL?

Я только начал использовать LINQ to SQL в проекте среднего размера и хотел бы лучше понять, какие преимущества предлагает L2S.

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

Я всегда хотел найти способ писать запросы в лучшей среде разработки. Являются ли запросы L2S решением, которое я искал? Или мы только что создали еще один слой поверх SQL, и теперь у нас вдвое больше поводов для беспокойства?

Ответов (5)

Решение

Преимущества L2S предлагает:

  • Никаких волшебных строк, как в SQL-запросах
  • Intellisense
  • Проверка компиляции при изменении базы данных
  • Более быстрое развитие
  • Шаблон единицы работы (контекст)
  • Автоматически созданные объекты домена, которые можно использовать в небольших проектах.
  • Ленивая загрузка.
  • Разработчикам .NET необходимо научиться писать запросы / лямбда-выражения linq.

По поводу производительности:

  • Скорее всего, производительность не будет проблемой для большинства решений. Предварительная оптимизация - это антипаттерн. Если позже вы увидите, что некоторые области приложения работают медленно, вы можете проанализировать эти части и в некоторых случаях даже поменять местами некоторые запросы linq с хранимыми процедурами или ADO.NET.
  • Во многих случаях функция отложенной загрузки может повысить производительность или, по крайней мере, значительно упростить код.

По поводу отладки:

  • На мой взгляд, отладка Linq2Sql намного проще, чем хранимые процедуры и ADO.NET. Я рекомендую вам взглянуть на Linq2Sql Debug Visualizer , который позволяет вам видеть запрос и даже запускать выполнение, чтобы увидеть результат при отладке.
  • Вы также можете настроить контекст для записи всех запросов sql в окно консоли, подробнее здесь

Что касается другого слоя:

  • Linq2Sql можно рассматривать как еще один уровень, но это чисто уровень доступа к данным. Хранимые процедуры - это еще один уровень кода, и я видел много случаев, когда часть бизнес-логики была реализована в хранимых процедурах. На мой взгляд, это намного хуже, потому что вы затем разделяете бизнес-уровень на два места, и разработчикам будет сложнее получить четкое представление о бизнес-области.

В качестве обновления вот несколько ссылок о будущем LINQ to SQL:

Какое будущее у Linq to SQL

Подтвердила ли Microsoft свою позицию по окончании срока службы LINQ to SQL?

LINQ to SQL жив или мертв?

Как говорится в комментарии к последней ссылке, LINQ to SQL никуда не денется, просто не будет «улучшен», по крайней мере, Microsoft. Принимайте эти комментарии и посты как хотите, только будьте осторожны в своих планах развития.

Недавно мы перешли на LINQ2Entity через среду Entity Framework. Раньше у нас были базовые адаптеры SQL. Поскольку база данных, с которой мы работаем, довольно мала, я не могу комментировать производительность LINQ.

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

Несколько быстрых мыслей.

LINQ в целом

  • Запрашивать коллекции в памяти и внепроцессные хранилища данных с одинаковым синтаксисом и операторами
  • Декларативный стиль очень хорошо работает с запросами - во многих случаях его легче читать и писать.
  • Аккуратная языковая интеграция позволяет писать новых поставщиков (как в процессе, так и вне его) и использовать один и тот же синтаксис выражения запроса.

LINQ to SQL (или другая база данных LINQ)

  • Написание запросов там, где они вам нужны, а не в виде хранимых процедур, значительно ускоряет разработку: требуется гораздо меньше шагов, чтобы получить нужные данные.
  • Намного меньше строк (хранимых процедур, имен параметров или просто SQL), где опечатки могут раздражать; другая сторона этой медали в том, что вы получаете Intellisense для своего запроса
  • Если вы не собираетесь работать с «сырыми» данными из ADO.NET, у вас все равно где-то будет объектная модель. Почему бы не позволить LINQ to SQL сделать это за вас? Мне больше нравится иметь возможность просто выполнить запрос и вернуть готовые к использованию объекты.
  • Я бы ожидал, что производительность будет хорошей - а там, где это не так, вы можете настроить ее самостоятельно или вернуться к прямому SQL. Использование ORM, безусловно, не устраняет необходимости в создании правильных индексов и т. Д., И вам обычно следует проверять генерируемый SQL на наличие нетривиальных запросов.

Это ни в коем случае не панацея, но я предпочитаю либо делать SQL-запросы напрямую, либо использовать хранимые процедуры.

Я должен сказать, что это то, что вы искали. К этому нужно время, чтобы привыкнуть, но как только вы это сделаете, вы не сможете думать о возвращении (по крайней мере, для меня). Что касается linq и хранимых процедур, у вас может быть низкая производительность, если вы построите его неправильно. Я перешел с linq на sql некоторые хранимые процедуры клиента, которые были ужасно закодированы, поэтому время упало с 20 секунд (совершенно неприемлемо для веб-приложения) до <1 секунды. И гораздо меньше кода, чем решение хранимой процедуры.

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