Мое понимание Linq to Sql - это принятие моей инструкции Linq и преобразование ее в эквивалентный оператор SQL.
Итак,
var products = from p in db.Products
where p.Category.CategoryName == "Beverages"
select p
Просто превращается в
Select * from Products where CategoryName = 'Beverages'
Если это произойдет, я не вижу, как хранимые процедуры больше полезны.
Sprocs - еще один инструмент в коробке. Вы можете использовать свой фантастический автоматически настраиваемый ключ для 90% ваших задач, но вы не можете использовать эту блестящую вещь на снятых гайках. Для этого хороший оловянный гаечный ключ - ваш лучший друг. Если вы не сломаете болт, в этом случае вы застряли в сборке.
Если это все, что вы делали в sql, раньше вам не нужны sprocs!
Безопасность.
Я видел несколько рекомендаций по обеспечению безопасности, которые рекомендуют вам делать все доступ к данным через SP, и вы предоставляете только привилегии для выполнения этих SP.
Если клиент просто не может делать select или delete в любых таблицах базы данных, риск может быть ниже, если клиент будет взломан.
Я никогда лично не работал над проектом, который работал таким образом, это всегда казалось гигантской болью на заднем плане.
А, тема многих дебатов.
В наши дни многие утверждают, что такие технологии, как LINQ-to-SQL, генерируют такой хороший SQL в наши дни, что преимущества производительности незначительны. Лично я предпочитаю, чтобы SQL-специалисты настраивали производительность SQL, а не общие кодеры, поэтому я склонен не соглашаться.
Однако мое основное предпочтение хранимым процедурам имеет меньшее отношение к производительности и больше относится к управлению безопасностью и конфигурацией.
Значительная часть моей архитектурной работы связана с сервис-ориентированными решениями и, рассматривая базу данных как услугу, значительно помогает использование хранимых процедур.
В принципе, ограничение доступа к базе данных посредством хранимых процедур создает четко определенный интерфейс, ограничивающий площадь поверхности атаки и увеличивающую тестируемость. Предоставление приложениям прямого доступа к базовым данным значительно увеличивает площадь поверхности атаки, снижает уровень безопасности и делает анализ воздействия чрезвычайно сложным.
Сохраненные процедуры и Linq to Sql решают разные проблемы.
Linq to Sql относится к Microsoft SQL Server.
Я предпочитаю использовать хранимые процедуры по нескольким причинам:
Недостатком является то, что может быть больно поддерживать код, который вызывает синхронизацию sprocs с базой данных, если ситуация быстро развивается. Вопросы, связанные с созданием эффективных запросов, могут считаться преждевременной оптимизацией. В конце концов, в условиях реалистичных нет замены для производительности бенчмаркинга.
Я могу придумать несколько веских причин для хранимых процедур:
Для небольшого приложения, поддерживаемого одним человеком, хранимые процедуры, вероятно, будут излишними.
При использовании хранимых процедур в соответствующих обстоятельствах существуют существенные связанные улучшения производительности на стороне SQL Server.
Поддержка хранимых процедур для LINQ to SQL была включена частично для совместимости с существующими системами. Это позволяет разработчикам с течением времени переходить из системы на основе sproc в полностью основанную на LINQ систему, sproc by sproc, а не заставлять разработчиков делать поспешное преобразование всей системы сразу.
Лично я не забочусь о LINQ. Мне нравится разделение материала манипуляции данными и кода. Кроме того, анонимные типы, которые генерируются из оператора LINQ, не могут быть переданы другим уровням приложения n-уровня, поэтому либо необходимо определить конкретный тип, либо вызвать LINQ-вызов в пользовательском интерфейсе. Gack!
Кроме того, есть проблемы с безопасностью (любой пользователь, вызывающий код LINQ в MS SQL Server, нуждается в неограниченном доступе к данным, поэтому, если это имя пользователя/пароль скомпрометированы, так же как и данные).
И, наконец, LINQ to SQL работает только для MS SQL Server (как это происходит из MS).
У Sprocs есть свои возможности, как и при использовании LINQ. IMO, если операция выполняется несколько раз в нескольких местах, тогда это хороший кандидат для "рефакторинга" в Stored Proc, в отличие от оператора LINQ, который повторяется в разных местах.
Кроме того, и это, вероятно, богохульство для многих людей здесь, иногда вы должны помещать некоторую логику в базу данных, а затем sproc пригодится. Это редкое явление, но иногда это требует бизнес-правил.
Хранимые процедуры полезны во многих случаях, но в целом, если вы используете ORM, вы должны позволить ORM генерировать SQL для вас. Зачем нам нужно поддерживать как минимум четыре хранимые процедуры (вставить обновление для удаления и один выбор) для каждой таблицы.
С учетом сказанного, как указали люди, существуют преимущества безопасности при использовании хранимых процедур. Вам не нужно предоставлять пользователям чтение/запись в таблицы, что является хорошей защитой от SQL Injection.
Сохраненные процедуры также полезны, когда логика, используемая для извлечения данных, довольно сложна. Вы, как правило, видите это в сценарии отчетов, и в этом случае ваш, вероятно, не использует Linq2Sql или какой-либо другой ORM.
На мой взгляд, если вы не генерируете свой SQL, а по существу жестко кодируете его в уровне приложения, то это должно быть реорганизовано в хранимые процедуры, и да всегда есть исключения для любых правил, но в целом.
Одно использование хранимой процедуры в Linq2Sql может быть, если у вас несколько серверов и связаны с ними, вы можете использовать хранимую процедуру для предоставления данных с этого другого сервера и управления им. Это скроет несколько серверов из вашего приложения.
Некоторые вещи не могут быть выполнены без хранимых процедур. Например, на моей предыдущей задаче существовала хранимая процедура, возвращающая текущее значение из строки и увеличивающая ее в той же атомной операции, что ни один из двух процессов не получил одинаковое значение. Я не помню, почему это было сделано вместо использования auto-increment, но для этого была причина.
Причина: большие объемы данных для перемещения из одной таблицы в другую.
Скажем, что время от времени вам приходится архивировать предметы из одной таблицы в другую или делать подобные вещи. С LINQ, который хотел бы получить, пусть скажет миллион строк из таблицы A в клиент DBMS, а затем вставляет их в таблицу B.
С хранимой процедурой все работает хорошо, в наборах.
Множество людей уже почти отлично обходится без них. Если вы можете сделать свою работу надежно и эффективно без них, не чувствуйте себя виноватым в том, что собираетесь с чистым L2S. Мы рады избавиться от них @моего магазина.
Вы, конечно, не нуждаетесь в хранимых процедурах. Но они могут пригодиться, если для вашей модели домена требуется сложная совокупная сущность, и у вас нет роскоши/гибкости для изменения таблиц базы данных в соответствии с моделью вашего домена. В этом случае использование Linq-to-SQL или другого ORM может привести к очень плохому набору вызовов базы данных для создания вашего Entity. Здесь хранится про запас.
Конечно, я бы рекомендовал использовать методологию или процесс, такие как TDD/BDD, который предоставляет вам гибкость для изменения таблиц базы данных по мере необходимости без особых проблем. Это всегда более легкий, более удобный путь, на мой взгляд.
Простой пример:
select * from Products where GetCategoryType(CategoryName)=1
GetCategoryType может работать очень быстро, потому что он работает на сервере БД. Насколько мне известно, Linq to SQL не заменяет это.
Я довольно поздно прихожу к этой теме. Но в зависимости от того, с кем вы говорите, Linq to SQL является dead, очень мертвый, или в лучшем случае зомби.
Кроме того, ни один инструмент не подходит для любой ситуации - вам нужно выбрать правильный инструмент для конкретной работы: