Почему люди используют linq для sql?

Позвольте мне перечислить вам несколько моментов:

1. Есть небольшие компании-разработчики программного обеспечения или компании среднего размера, которые разрабатывают свое программное обеспечение собственными силами, которые могут скорее сосредоточиться на привлечении многих разработчиков приложений, чем на получении внештатный разработчик БД или даже нанять его на постоянной основе.
2. В большинстве случаев накладные расходы не являются проблемой либо из-за объема данных, которые необходимо обработать, либо из-за низкого трафика. Кроме того, при правильном использовании LINQ to SQL может работать так же быстро, как и большинство запросов SQL + связанный с ними код .net.
3. Многие компании просто придерживаются стека Microsoft, и им остается только наслаждаться интеграцией. Другая компания разрабатывает SOA, и здесь нет никаких проблем. Других не заставляют выбирать LINQ-to-SQL, и если они сделают этот выбор, их проблема - как его интегрировать. Никто никогда не говорил, что LINQ-to-SQL - это серебряная пуля: )
4. Я считаю, что безопасность достигается с LINQ-to-SQL, потому что я наткнулся на множество SQL-запросов, принимающих неэкранированные данные с конкатенацией строк и т. Д., И объяснение всей идеи параметризованного запроса никогда не было легким . Кроме того, поскольку все запросы в конечном итоге переводятся в SQL, если описываемая вами проблема отслеживания не возникает через хранимую процедуру, опять же нет никаких проблем.

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

Существующие вопросы / ответы в том же духе / духе:

• Не упускает ли Linq to SQL главное? Разве ORM-mappers (SubSonic и т. Д.) Не являются неоптимальными решениями?
• LINQ-to-SQL против хранимых процедур?
• Что не так с Linq to SQL?
• Зачем мне нужны хранимые процедуры, когда я есть LINQ to SQL
• Если вы используете LINQ to SQL, есть ли какие-то веские причины для изучения SQL-запросов / синтаксиса?
• https://stackoverflow.com/questions/216569/are-the-days-of-the- пронумерованная хранимая процедура

Лично я считаю, что нет правильного или неправильного ответа. Это зависит от того, что вы разрабатываете и как вы это развиваете. Если вам нужна высокая производительность, слишком сложная модель данных и т. Д., Пропустите абстракцию. Если вы чувствуете, что абстракция ускоряет время разработки,

Проблема в том, что очень редко где-нибудь есть компетентный разработчик SQL, который любит писать SQL и не хотел бы заниматься чем-то другим. Я бы считал себя компетентным в SQL, я использовал все свои уровни доступа к данным с сохраненными процессами или параметризованными запросами. Проблема в том, что это требует времени и скучно. Я бы предпочел писать отличные приложения, чем возиться со слоями доступа к данным, в которых, по сути, есть SQL-оператор select, insert, update и delete (или процедура), повторяемый десятки раз для каждого объекта данных.

Linq-to-SQL требует убрать часть повторяющейся природы. У него есть инструмент для автоматического создания бизнес-объектов из схемы вашей базы данных, и он дает вам хороший интегрированный язык запросов, который проверяется во время компиляции и находится в вашем коде (сохраненные процессы - это проблема для управления исходным кодом аккуратно)

Я могу написать DAL в Linq-to-sql в несколько раз быстрее, чем я могут использовать простой SQL, хранимые процессы или параметризованные запросы.

Если вы хотите сохранить использование хранимых процедур, и linq-to-sql, и EF поддерживают использование хранимых процедур для всего доступа к данным, вам просто нужно настроить соответствующие сопоставления. Таким образом, вы все равно можете использовать сохраненные процедуры для регистрации деталей и реализации безопасности, если хотите. Мы, как правило, выбираем использование Windows auth и используем его для ограничения доступа к каждой таблице для различных пользователей, тогда у нас есть набор триггеров в таблицах, которые отслеживают детали для целей аудита.

Я быстро отмечу две вещи: что во-первых, фреймворк entity, похоже, получает больше поддержки со стороны MS в настоящее время, и я подозреваю, что это будет считаться стандартом по умолчанию для будущего, а не linq-to-sql. Во-вторых, в .Net 3.5 EF и linq-to-sql не очень хорошо поддерживают n-уровневые отключенные приложения. В обоих случаях вам как бы придется возиться с сериализацией контекстов данных на отключенных уровнях или вручную отсоединять и повторно присоединять объекты данных. Однако это значительно улучшено в .net 4.0. Просто подумайте о том, какая версия у вас доступна.

В обоих случаях вам как бы придется возиться с сериализацией контекстов данных на отключенных уровнях или вручную отсоединять и повторно присоединять объекты данных. Однако это значительно улучшено в .net 4.0. Просто подумайте о том, какая версия у вас доступна.

В обоих случаях вам как бы придется возиться с сериализацией контекстов данных на отключенных уровнях или вручную отсоединять и повторно присоединять объекты данных. Однако это значительно улучшено в .net 4.0. Просто подумайте о том, какая версия у вас доступна.

Для меня на запись linq в код sql уходит гораздо меньше времени, чем на написание набора хранимых процедур. Это особенно верно, когда дизайн еще не закончен, в этом случае я еще не знаю, какую часть работы я хочу сделать с объектами C # и сколько я хочу сделать в SQL.

Итак, я могу пропустить создание наборов данных, мне не нужно щелкать щелчком мыши, чтобы добавить запросы, в основном, linq to sql означает, что я могу изменить свой код за меньшее время.

Кроме того, как большой поклонник Haskell, я могу написать много функциональных код в стиле с linq to sql, и он просто работает.

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

Кроме того, я считаю, что операторы LINQ легче читать, чем SQL.

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

Я работал над приложением, в котором код был полностью изолирован от базы данных, за исключением набора открытых хранимых процедур. Код не мог ничего «знать» о схеме базы данных, за исключением того, что он был возвращен из сохраненных процессов.

Хотя это не так уж необычно и нетрудно написать DAL с использованием ADO или чего-то еще, я решил попробуйте Linq to Sql, даже если он не будет использовать его по прямому назначению и не будет использовать большинство функций. Оказалось, что это было отличное решение.

Я создал класс Linq to Sql, перетащил сохраненные процессы из проводника сервера в правую часть дизайнера, потом ... Погодите, нет тогда. Я почти закончил.

Linq создал строго типизированные методы для каждой хранимой процедуры. Для процедур, возвращающих строки данных, Linq автоматически создает класс для элементов в каждой строке и возвращает для них List . Я обернул сами вызовы в легкий общедоступный класс DAL, который провел некоторую проверку и автоматическую настройку параметров, и все готово. Я написал класс бизнес-объекта и сопоставил динамически сгенерированные объекты класса Linq с бизнес-объектом (сделал это вручную, но это несложно сделать или поддерживать).

Теперь программа невосприимчива к любым изменениям схемы, которые не соответствуют не влияет на подписи хранимых процедур. Если подписи меняются, мы просто перетаскиваем старую процедуру из дизайна и перетаскиваем ее обратно, чтобы регенерировать код. Несколько проходов через модульные тесты для внесения изменений (которые обычно не выходят за рамки общедоступного интерфейса DAL), и готово. Вещи, предшествующие DAL, используют методы Linq to Objects для выбора, фильтрации и сортировки данных, которые не в правильном формате, прямо из вызовов хранимых процедур.

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

Для очень простых запросов накладные расходы на дополнительный уровень добавляют к стоимости двустороннего обращения. Для несколько более сложных запросов в обычных сценариях «бизнес-приложений» оптимизация, выполняемая с помощью магии преобразования Linq-to-SQL-> sql, часто может значительно сэкономить.

В качестве примера я недавно сделал перевод 1: 1 поставленной заказчиком 1400+ (!) линии хранится в L2S. Он не только перешел с 1400 строк SQL до 500 строк гораздо более читаемого, строго типизированного и комментируемого кода. Он также начал попадать в базу данных со средним значением ~ 1500 чтений вместо ~ 30k чтений. Это было еще до того, как я начал изучать оптимизацию на стороне БД - это экономия - это то, что я могу на 100% приписать способности L2S исключать предикаты, которые можно оценить на стороне клиента.

Это может быть случай, когда удобство берет верх над производительностью. Если вы программируете на уровне сверхпроизводительности Facebook, вы можете думать о каждом тактовом цикле, но простая истина заключается в том, что большинству приложений не нужно это внимание и они получают выгоду от эффективности обслуживания кода и времени разработки (100 тыс. Подрядчик против . another $ erver).

Тем не менее, есть случай передать на аутсорсинг такую ​​же большую часть обработки запросов из блока БД в очень крупномасштабных системах, иначе БД является узким местом, и вам нужно сегментировать или перестроить линия.

Я думаю, будет справедливо сказать, что LINQ будет лучше / проще масштабироваться как с точки зрения серверов, так и с точки зрения многих ядер, поскольку ваша кодовая база LINQ получит m-core «бесплатно», как только MS выпустит C # 4.0.

Я понимаю, что вы спрашиваете и как не-ASP. NET dev только начинает свой проект www в первый раз, я не вижу смысла 80% ASP.NET (темы, элементы управления и т. Д.) - кажется, мне нужно больше узнать и кодировать больше, чем сам HTML! - опять же, я уверен, что для всего этого есть веская причина.

--- У меня нет 50 баллов, чтобы прокомментировать сообщение, которое я хочу, поэтому я делаю это здесь ---

Дэвид Б. предполагает, что написание некоторого количества SQL - это все, что нужно для получения максимальной отдачи от SQL Server, и что использование подсказок в запросах является механизмом управления. Одна и та же задача может быть решена в SQL разными способами, и многие из них с приростом производительности в тысячи раз. Предлагаю прочитать «Внутренние запросы T-SQL» (Ицик Бен Ган). Снова и снова Ицик показывает, как переосмыслить запрос и использовать новые команды, чтобы уменьшить количество логических операций чтения иногда с тысяч до менее десяти.

NET (темы, элементы управления и т. Д.) - кажется, мне нужно больше учиться и кодировать больше, чем сам HTML! - опять же, я уверен, что для всего этого есть веская причина.

--- У меня нет 50 баллов, чтобы прокомментировать сообщение, которое я хочу, поэтому я делаю это здесь ---

Дэвид Б. предполагает, что написание некоторого количества SQL - это все, что нужно для получения максимальной отдачи от SQL Server, и что использование подсказок в запросах является механизмом управления. Одна и та же задача может быть решена в SQL разными способами, и многие из них с приростом производительности в тысячи раз. Предлагаю прочитать «Внутренние запросы T-SQL» (Ицик Бен Ган). Снова и снова Ицик показывает, как переосмыслить запрос и использовать новые команды, чтобы уменьшить количество логических операций чтения иногда с тысяч до менее десяти.

NET (темы, элементы управления и т. Д.) - кажется, мне нужно больше учиться и кодировать больше, чем сам HTML! - опять же, я уверен, что для всего этого есть веская причина.

--- У меня нет 50 баллов, чтобы прокомментировать сообщение, которое я хочу, поэтому я делаю это здесь ---

Дэвид Б. предполагает, что написание некоторого количества SQL - это все, что нужно для получения максимальной отдачи от SQL Server, и что использование подсказок в запросах является механизмом управления. Одна и та же задача может быть решена в SQL разными способами, и многие из них с приростом производительности в тысячи раз. Предлагаю прочитать «Внутренние запросы T-SQL» (Ицик Бен Ган). Снова и снова Ицик показывает, как переосмыслить запрос и использовать новые команды, чтобы уменьшить количество логических операций чтения иногда с тысяч до менее десяти.

- веская причина для всего этого.

--- У меня нет 50 пунктов, чтобы прокомментировать сообщение, которое я хочу, поэтому я делаю это здесь ---

Дэвид Б. предлагает написать немного SQL это все, что нужно для получения максимальной отдачи от SQL Server, а использование подсказок в запросах - это механизм управления. Одна и та же задача может быть решена в SQL разными способами, и многие из них с приростом производительности в тысячи раз. Предлагаю прочитать «Внутренние запросы T-SQL» (Ицик Бен Ган). Снова и снова Ицик показывает, как переосмыслить запрос и использовать новые команды, чтобы уменьшить количество логических операций чтения иногда с тысяч до менее десяти.

- веская причина для всего этого.

--- У меня нет 50 пунктов, чтобы прокомментировать сообщение, которое я хочу, поэтому я делаю это здесь ---

Дэвид Б. предлагает написать немного SQL это все, что нужно для получения максимальной отдачи от SQL Server, а использование подсказок в запросах - это механизм управления. Одна и та же задача может быть решена в SQL разными способами, и многие из них с приростом производительности в тысячи раз. Предлагаю прочитать «Внутренние запросы T-SQL» (Ицик Бен Ган). Снова и снова Ицик показывает, как переосмыслить запрос и использовать новые команды, чтобы уменьшить количество логических операций чтения иногда с тысяч до менее десяти.

m делаю это здесь ---

Дэвид Б. предполагает, что написание некоторого количества SQL - это все, что нужно для получения максимальной отдачи от SQL Server, и что использование подсказок в запросах является механизмом управления. Одна и та же задача может быть решена в SQL разными способами, и многие из них с приростом производительности в тысячи раз. Предлагаю прочитать «Внутренние запросы T-SQL» (Ицик Бен Ган). Снова и снова Ицик показывает, как переосмыслить запрос и использовать новые команды, чтобы уменьшить количество логических операций чтения иногда с тысяч до менее десяти.

m делаю это здесь ---

Дэвид Б. предполагает, что написание некоторого количества SQL - это все, что нужно для получения максимальной отдачи от SQL Server, и что использование подсказок в запросах является механизмом управления. Одна и та же задача может быть решена в SQL разными способами, и многие из них с приростом производительности в тысячи раз. Предлагаю прочитать «Внутренние запросы T-SQL» (Ицик Бен Ган). Снова и снова Ицик показывает, как переосмыслить запрос и использовать новые команды, чтобы уменьшить количество логических операций чтения иногда с тысяч до менее десяти.

повторите за мной (минимум 3 раза)

• нет серебряной пули

• Я не буду использовать технологию только потому, что это последняя разработка от MSFT

• Я не буду использовать что-то, чтобы включить это в свое резюме

Не только их компетентные программисты SQL, но и любой достойный программист приложений, особенно LOB-приложений, должен писать промежуточный SQL. Если вы не знаете SQL и пишете LINQ to SQL, как вы собираетесь отлаживать вызовы данных? Как вы собираетесь профилировать их, чтобы устранить узкие места?

Мы пробуем LINQ to SQL, и я думаю, что у него есть серьезные проблемы, такие как:

• Нет простого способа вернуть результаты запроса другому объект. Это само по себе кажется безумием. Microsoft создала анонимный тип данных var и рекомендует его использовать, но нет возможности переместить эти данные из вашего локального метода, следовательно, парадигма oo нарушается, если вы должны использовать данные в той же функции, которая их получила.

• Таблицы НЕ являются объектами. Изучите 3-ю нормальную форму и т. Д. Реляционные базы данных предназначены для хранения данных, а не для их использования. Я не хочу, чтобы меня ограничивали или поощряли использовать мои таблицы в качестве объектов. Данные, которые я извлекаю из базы данных, очень часто являются объединениями нескольких таблиц и могут включать приведение типов SQL, функции, операторы и т. Д.

• Нет прироста производительности и небольшая потеря

• Теперь у меня есть намного больше кода беспокоиться о. Есть файлы dbml и еще DAL для записи LINQ. Да, многие из них сгенерированы машиной, это не означает, что ее там нет, это что-то еще, что может пойти не так (например, ваши файлы dbml и т. Д.).

Теперь, когда я предоставил фон, я попытаться ответить на ваш актуальный вопрос, почему люди используют LINQ To SQL:

• Это последняя разработка от Microsoft, и я хочу, чтобы это было в моем резюме.
• Msft убедила менеджеров / руководителей, что это уменьшит время написания кода
• Разработчики ненавидят SQL. (нет хорошей среды разработки или отладки, кроме как вручную - было бы неплохо иметь лучший intellisense для инструмента sql.)

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

Простой ответ, есть два подхода: создать изысканные хитрые устройства Руба Голдберга или просто выполнить работу простым способом. Многие разработчики склоняются к первому.

Разработчикам быстро становится скучно, и им часто нравится делать вещи посложнее, что, кажется, обеспечивает определенную интеллектуальную красоту. Вы разрабатываете приложение или пишете докторскую диссертацию? Как обычно кричал в коридоре мой директор MSF: «Мне не нужен еще один исследовательский проект!»