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

Ответ 1

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

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

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

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

Здесь точка-точка:

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

• Не 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-stored-procedure-numbered

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

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

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

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

Ответ 7

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

Плюс я считаю, что инструкции LINQ легче читать, чем SQL.

Ответ 8

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

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

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

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

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

Дэвид Б предполагает, что писать какой-то SQL - все, что нужно, чтобы получить максимальную отдачу от SQL Server, и что использование подсказок подсказок - это механизм рулевого управления. Та же задача может быть достигнута разными способами в SQL, и многие из них в 1000 раз увеличивают производительность. Я предлагаю прочитать Inside T-SQL Querying (Itzik Ben Gan). Снова и снова Itzik показывает, как переосмыслить запрос и использовать новые команды для сокращения логических чтений, иногда от тысяч до менее десяти.

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

повторите после меня (мин. 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 убедил менеджеров /execs, что это уменьшит время кодирования
• Разработчики ненавидят SQL. (без хорошей среды разработки или отладки, кроме как вручную), было бы неплохо иметь лучший интеллект для инструмента sql.)

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