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

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

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

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

Ответы

Ответ 1

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

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

Что касается производительности:

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

Что касается отладки:

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

Относительно другого уровня:

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

Ответ 2

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

LINQ в целом

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

LINQ to SQL (или другая LINQ LINQ)

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

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

Ответ 3

Так же, как и обновление, вот некоторые ссылки на будущее LINQ to SQL:

Что такое будущее Linq для SQL

Подтвердила ли Microsoft свою позицию по поводу завершения работы LINQ до SQL?

Является ли LINQ to SQL мертвым или живым?

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

Ответ 4

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

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

Ответ 5

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

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