Linq2Sql против хранимых процедур

Question

Извините, если это дублирующий вопрос, но есть ли реальная разница между выполнением оператора SQL в Linq2Sql по сравнению с выполнением хранимой процедуры?

Каковы преимущества? (если есть)

Answer 1

Если исходная скорость равна , то используйте DataReader.

В противном случае LINQ to SQL является надежной альтернативой. Он предлагает огромные преимущества с точки зрения строгого именования и безопасности типов. Это значительное повышение производительности. Когда вы научитесь писать хорошие запросы LINQ и, в частности, научитесь использовать скомпилированные запросы там, где это уместно, вы сможете получить очень приличную производительность.

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

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

Answer 2

Если вы поместите свой код в хранимую процедуру, вы отделите его от своего приложения C #. Вы можете исправить любые ошибки или расширить его функциональность, не перекомпилируя и не перераспределяя ваше приложение.

Кроме того, использование хранимой процедуры может быть мерой безопасности: вы можете предоставить своим пользователям разрешение на выполнение хранимых процедур, но не можете обновлять или вставлять привилегии для базовых таблиц. Это может сделать вашу базу данных более безопасной и более управляемой.

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

Answer 3

Одним из невероятных преимуществ LINQ to SQL над хранимыми процедурами является то, что вы можете динамически создавать запрос.

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

Используя логику управления потоком и цепочку запросов, вы можете создать более простой запрос, который использует только те параметры, которые активны в поиске, исключая проверки или альтернативную логику, необходимые для устранения случаев, когда необязательные параметры не предоставляются. Используя Dynamic LINQ и / или PredicateBuilders , эти запросы также могут быть произвольно сложными, но все же проще, чем те, которые реализуются хранимой процедурой.

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

Другое преимущество LINQ, IMO, заключается в том, что он позволяет разработчику писать запросы, используя более естественные идиомы (в моем случае, C #). Хотя я могу писать на SQL, для меня более естественно писать код на C #. Я лучше и быстрее в этом.