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

Question

С учетом предпосылки:

• Есть компетентные программисты sql (корреляция - написание sql запросов не проблема)
• Есть компетентные разработчики приложений (корреляция - существует простая / сильная / гибкая архитектура для обработки соединений и простых запросов из кода)

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

• С каждой транзакцией добавляются накладные расходы
• Существует большая вероятность потери производительности для вычислений средней сложности (БД созданы для обработки наборов и вычислений, и команды инженеров занимались оптимизацией - зачем возиться с этим?)
• Существует потеря гибкости (если вы хотите добавить другой пользовательский интерфейс (не приложение .NET) или метод доступа, вам нужно либо вернуть запросы обратно в БД, либо создать отдельный слой доступа к данным)
• Существует потеря безопасности из-за отсутствия централизованного управления записью / обновлением / чтением в БД (например, запись изменилась - если вы разрешаете приложениям использовать linq для sql для обновления, то вы не можете доказать, какое приложение изменилось это или какой экземпляр приложения изменил его)

Я продолжаю видеть вопросы о linq to sql и мне интересно, что я что-то упустил.

Answer 1

Я продолжаю видеть вопросы о linq to sql, и мне интересно, что я что-то упустил.

Дело не в том, что вы что-то упускаете. Это то, что у вас есть то, чего нет в большинстве магазинов:

Есть компетентные программисты sql

Кроме того, в вашем магазине эти компетентные программисты SQL предпочитают писать SQL.

---

Вот ответ по пунктам:

С каждой транзакцией добавляются накладные расходы

Как правило, правда. Этого можно избежать, переведя запросы до того, как они потребуются для запуска, используя CompiledQuery для многих (но не всех!) Сценариев.

Существует большая вероятность потери производительности для вычислений средней сложности (БД созданы для обработки наборов и вычислений, и команды инженеров занимались оптимизацией - зачем возиться с этим?)

Либо вы пишете linq, который переводится в sql, а затем из оптимизатора генерируется план, либо вы пишете sql, из которого оптимизатор создает план. В обоих случаях вы говорите машине, что вы хотите, и она должна выяснить, как это сделать. Вы предполагаете, что подрыв оптимизатора с помощью подсказок к запросу является хорошей практикой? Многие компетентные программисты sql не согласятся с этим предложением.

Существует потеря гибкости (если вы хотите добавить другой пользовательский интерфейс (не .NET-приложение) или метод доступа, вы должны либо поместить запросы обратно в БД, либо создать отдельный слой доступа к данным)

Многие люди, использующие linq, уже являются SOA. Линк живет в службе. Приложение не .NET вызывает сервис. Бада-бинг-бада-бум.

Существует потеря безопасности из-за отсутствия централизованного управления записью / обновлением / чтением в БД (например, запись изменилась - если вы разрешаете приложениям использовать linq для sql для обновления, то вы не можете доказать, какое приложение изменилось это или какой экземпляр приложения изменил его)

Это просто неправда. Вы проверяете, какое приложение подключено и выдает команды sql, точно так же, как доказываете, какое приложение подключено, и вызываете sproc.

Answer 2

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

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, и все же большая часть того, что я сказал, будет верна.

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

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

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

Answer 6

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

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

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

Answer 7

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

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

Answer 8

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

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

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

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

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

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

Answer 9

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

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

Answer 10

Пожалуйста, повторите за мной (мин. 3 раза)

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

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

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

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

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

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

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

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

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

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

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

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