Обеспечивает ли LINQ To SQL более быстрое время отклика, чем использование ado.net и oledb?

Это спектакль Максимилиана Беллера. По его словам, LINQ намного медленнее. Прочтите его подробное исследование

Это зависит от того, что вы делаете. LINQ будет менее эффективным при фактическом манипулировании данными / набором, чем реальная база данных. Но вы сэкономите много, поскольку вам не придется подключаться к базе данных по сети.

Если ваша база данных находится на том же компьютере или формально «хорошо связана», вам, вероятно, лучше ее использовать.

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

Если вас интересует сравнительный анализ, у Rico Mariani есть отличное исследование из 5 частей, который охватывает качественные и количественные различия.

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

Подумайте об изменении имени столбца - теперь измените (n) SP и (x) Views.

Сделайте все, что дорого в базе данных (например, поиск, сортировка и т. д.), И вы не заметите проблемы.

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

StackOverflow также использует linq2sql - вы видите проблему :)?

Используйте ORM - так работает в большинстве приложений.

PS: также по поводу микротестов - вроде .. давайте выберем 10.000 строк с ORM - НЕ ДЕЛАЙТЕ ЭТО. Не поэтому вы используете ORM. Если вы хотите выбрать 10.000 строк, используйте ADO.

Из-за структуры LINQ to SQL невозможно использовать Быстрее, кроме как использовать необработанный SQL, будь то ваши собственные правильно сформированные запросы или хранимая процедура. LINQ покупает вам не скорость, а безопасность типов и организацию; Короче говоря, большинство преимуществ, которые обычно предоставляют вам ORM.

LINQ to SQL - это не скорость, а создание более удобной в обслуживании программной системы. Речь идет обо всем, о чем заботятся специализированные инженеры-программисты и архитекторы, таких как слабая связь и многоуровневость

Это не значит, что вы не можете создать какой-то действительно неподдерживаемый код с LINQ - никто не мешает вам выстрелить себе в ногу, кроме вас, - но если все сделано правильно, LINQ может очень помочь. Однако я не говорю, что LINQ - это серебряная пуля. У него есть множество проблем, которые затрудняют использование во многих корпоративных ситуациях, поэтому MS предлагает Entity Framework (ADO.NET 3.0). Конечно, даже это не идеально с учетом недавнего вотума недоверия EF.

LINQ to SQL или даже EF лучше, чем необработанный SQL? Я бы сказал громкое Hells Yeah. Есть ли другие решения, которые могут работать лучше? Может быть.

LINQ to SQL на самом деле представляет некоторые тревожные проблемы с производительностью в базе данных. По сути, он создает несколько планов выполнения в зависимости от длины используемого вами параметра. Я писал об этом некоторое время назад в моем блоге LINQ to SQL может вызвать проблемы с производительностью.

Итак, можно ли сказать, что LINQ нет места? Едва ли. LINQ определенно имеет место в наборе инструментов разработки, как и хранимые процедуры. В конечном итоге вы хотите использовать хранимые процедуры, когда производительность абсолютно необходима, и использовать инструмент ORM в любой другой ситуации.

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

Как и большинство решений для баз данных, правильный ответ зависит от проблемы, которую вы пытаетесь решить. Если вы предпочитаете скорость разработки производительности базы данных / приложения, то лучшим вариантом будет использование LINQ или другого инструмента DAL / ORM. Если вы предпочитаете производительность простоте разработки, то лучшим выбором будет использование хранимых процедур и чистых наборов данных. LLBLGen даже предоставляет уровень LINQ to LLBLGen, так что вы можете использовать LINQ для запроса объектов LLBLGen, а LLBLGen действительно обрабатывает построение ваших запросов и избегает некоторых неудач LINQ.

Ваша основная предпосылка ошибочна ..

Inline SQL requires one to communicate with the database in a certain way that opens the database to injections.

Нет, это не так. Жесткое кодирование значений, вводимых пользователем, в оператор SQL делает это, но вы также можете сделать это с помощью процедур хранения.

Параметризация запросов защищает от атак с использованием инъекций, но встроенный SQL можно параметризовать так же легко, как и хранимые процедуры.

Inline SQL must also be syntax-checked, have a plan built, and then executed.

Все Sql (SP и встроенные) должны быть проверены синтаксисом и иметь план, построенный на их первом вызове. После этого точный текст запроса и план выполнения кешируются. Если получен другой запрос с точно таким же текстом (без учета параметров), используется кэшированный план выполнения.

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

Другими словами, единственная проблема со встроенным SQL заключается в том, что легко делать что-то медленное и небезопасное. Но сделать встроенный SQL быстрым и безопасным - это не работа, чем использование SP.

Это подводит нас к LINQ, который всегда использует параметры, даже если вы жестко закодируете значения в операторе LINQ, что делает «быстрый и безопасный» встроенный SQL тривиальным.

LINQ также имеет преимущество перед SP в том, что весь ваш код находится в одном месте, а не разбросан по двум разным машинам.