Каковы преимущества LINQ to SQL?

Question

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

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

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

Answer 1

Преимущества L2S предложения:

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

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

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

Относительно отладки:

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

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

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

Answer 2

Всего несколько быстрых мыслей.

LINQ в целом

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

Answer 5

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

Должен признать, что написание запросов стало намного проще, а добавление сущностей действительно позволяет строго печатать.