LINQ К SQL обеспечивают более быстрое время отклика, чем использование ado.net и oledb?
Как будто вы пытаетесь получить доступ к объекту, который является null. Рассмотрим ниже пример:
TypeA objA;
. В это время вы только что объявили этот объект, но не инициализировали или не инициализировали. И всякий раз, когда вы пытаетесь получить доступ к каким-либо свойствам или методам в нем, он будет генерировать NullPointerException, что имеет смысл.
См. Также этот пример:
String a = null;
System.out.println(a.toString()); // NullPointerException will be thrown
7 ответов
LINQ к SQL на самом деле представляет некоторые сигнализирующие проблемы производительности в базе данных. В основном это создает несколько планов выполнения на основе длины параметра, который Вы используете. Я отправил об этом некоторое время назад на моем блоге, LINQ к SQL может вызвать проблемы производительности.
Теперь, это должно сказать, что LINQ не имеет места? Едва. LINQ определенно имеет место в инструментарии разработки, точно так же, как хранимые процедуры. В конечном счете Вы хотите использовать хранимые процедуры, когда производительность абсолютно необходима, и используйте инструмент ORM в любой другой ситуации.
Насколько встроенный SQL идет, существуют способы выполнить встроенный SQL так, чтобы план был только создан однажды и никогда не был перекомпилирован. Большая часть ORMs должна заботиться об этом аспекте производительности, настраивающейся также, и использующий эти методы обычно самый безопасный способ выполнить Ваш SQL, так как это вынуждает Вас использовать параметризированные запросы.
Как большинство решений для базы данных, правильный ответ зависит от проблемы, которую Вы пытаетесь решить. Если Вы одобряете скорость разработки по базе данных/производительности приложения, то использование LINQ или другого инструмента DAL/ORM является лучшим способом пойти. Если Вы одобряете производительность по простоте разработки, то использование хранимых процедур и чистых наборов данных будет Вашим лучшим выбором. LLBLGen даже предоставляет LINQ уровню LLBLGen, таким образом, можно использовать LINQ, чтобы запросить объекты LLBLGEN и иметь LLBLGen, на самом деле обрабатывают создание запросов и избегают некоторых крушений LINQ.
Ваша основная предпосылка испорчена..
Встроенный SQL требует, чтобы общался с базой данных определенным способом, который открывает базу данных для инжекций.
Нет это не делает. Введенные пользователями значения жесткого кодирования в SQL-оператор делают, но Вы могли сделать это с процедурами хранилища также.
Параметризация Ваших запросов принимает меры против инжекционных нападений, но встроенный SQL может параметризовать так же легко как хранимые процедуры.
Встроенный SQL должен также быть проверен в синтаксисе, создать план, и затем выполняемый.
Весь Sql (SPS и встроенный) должен быть проверен в синтаксисе и основываться на плане их первый вызов. После этого точный текст запроса и план выполнения кэшируются. Если другой запрос с тем же самым текстом (не считающий параметры) получен, кэшируемый план выполнения используется.
Так, если Вы, которым твердым кодовым обозначениям во встроенный SQL, текст не будет соответствовать, и он должен будет повторно проанализировать запрос. Однако при использовании параметров текст запроса будет соответствовать, и Вы получите удачное обращение в кэш. В этом случае это не имело бы значения если запрос во встроенном SQL или SP.
Другими словами, единственная проблема со встроенным SQL состоит в том, что он легкий сделать что-то это замедляется и небезопасный. Но создание встроенного SQL быстро и безопасный больше не является работы то использование SP.
Который приносит нам к LINQ, который всегда с помощью параметров, даже если Вы твердый код значения в оператор LINQ, делая "быстро и безопасный" встроенный SQL тривиальный.
LINQ также имеют преимущество перед SPS наличия всего Вашего кода в одном месте вместо рассеянного более чем две различных машины.
Если Вы интересуетесь сравнительным тестированием, у Rico Mariani есть превосходное исследование с 5 частями, которое покрывает качественные и количественные различия.
Он может быть парнем MS, но он известен как гайка производительности - его сравнительные тесты полны и хорошо продуманные.
Это - производительность, выполненная Maximilian Beller. По его словам, LINQ намного намного медленнее. Считайте его всестороннее исследование
Это зависит от того, что Вы делаете. LINQ будет менее эффективным при фактическом управлении данными/набором, чем реальная база данных. Но Вы сохраните много в не необходимости соединиться с базой данных по сети.
Если Ваша база данных находится на той же машине или официально 'имеет хорошие связи', Вы - вероятно, более обеспеченное использование ее.
Но если Вы возвращаете большой набор результатов от удаленного дб, который мог бы означать значительное время передачи, или если это - действительно короткий запрос, который не выровняет по ширине издержки, LINQ, вероятно, был бы лучше.
Из-за структуры LINQ к SQL нет никакого возможного способа, которым это может быть быстрее, чем использование необработанного SQL, или Ваши собственные правильно построенные запросы или как хранимая процедура. То, что LINQ покупает Вас, не является скоростью, но безопасностью типов и организацией; короче говоря большинство преимуществ, которые ORMs обычно предоставляют Вам.
LINQ к SQL не о скорости, это о создании более удобной в сопровождении программной системы. Это о выделенной заботе Разработчиков программного обеспечения и Архитекторов всего материала о, материал как слабая связь и разделение на уровни
Но это вовсе не значит то, что Вы не можете создать некоторый действительно неудобный в сопровождении код с LINQ - никто не мешает Вам стрелять себе в ногу, но Вы - но сделанный правильно, LINQ может помочь чрезвычайно. Я не говорю, что LINQ является серебряной пулей, как бы то ни было. Это имеет хост проблем, которые мешают использовать во многих ситуациях предприятия - который является, почему MS предлагает Платформу Объекта (ADO.NET 3.0). Конечно, даже это не прекрасно, учитывая недавний Вотум недоверия EF.
LINQ к SQL или даже EF лучше, чем необработанный SQL? Я сказал бы звучный Ад Да. Есть ли другие решения, которые могли бы работать лучше? Возможно.
Просто думайте о том, чтобы менять имя столбцов - теперь изменяют (n) SPS и (x) Представления.
Сделайте все, что дорого на базе данных (как поиски, сортируя и т.д.) и Вы не заметите проблемы.
Кроме того, если Вы хотите отобразиться, большая сетка без подкачки страниц... затем используют набор данных - что каждый быстрее.
StackOverflow также использует linq2sql - делают Вы видите проблему :)?
Используйте ORM - это - способ пойти на большинство приложений.
PS: также, о микро сравнительных тестах - как.. давайте выберем 10 000 строк с ORM - не ДЕЛАЮТ IT. Это не то, почему Вы используете ORM. Если Вы хотите выбрать 10 000 использования строк ADO.