Хранимые процедуры Entity Framework против сгенерированного SQL

Question

Я использовал структуру сущностей в нескольких проектах. В каждом проекте я использовал хранимые процедуры, сопоставленные с сущностями, из-за хорошо известных преимуществ хранимых процедур - безопасности, удобства обслуживания и т. Д. Однако 99% хранимых процедур - это базовые хранимые процедуры CRUD. Похоже, что это сводит на нет одну из основных, экономящих время функций Entity Framework - генерацию SQL.

Я прочитал некоторые аргументы относительно хранимых процедур и сгенерированного SQL из Entity Framework. Хотя использование CRUD SP лучше для безопасности, а SQL, генерируемый EF, часто более сложен, чем необходимо, действительно ли он что-то приобретает с точки зрения производительности или удобства использования SP?

Вот что я верю:

• В большинстве случаев изменение SP требует обновления модели данных. тем не мение. Таким образом, это не покупает много с точки зрения ремонтопригодности.
• Для веб-приложений при подключении к базе данных используется один идентификатор пользователя, определенный для приложения. Таким образом, пользователи даже не имеют прямого доступа к базе данных. Это уменьшает выгоду безопасности.
• Для небольшого приложения немного снижена производительность при использовании сгенерированный SQL, вероятно, не будет большой проблемой. Для высоких объем, критически важные приложения, EF будет даже мудрым выбор? Кроме того, генерируются ли операторы вставки / обновления / удаления? EF действительно так плохо?
• Отправка каждого атрибута в хранимую процедуру имеет свои собственные ограничения производительности, тогда как сгенерированный EF-код отправляет только те атрибуты, которые действительно были изменены. При выполнении обновлений для больших таблиц увеличение сетевого трафика и накладных расходов на обновление всех атрибутов, вероятно, сводит на нет выигрыш в производительности хранимых процедур.

С учетом сказанного мои конкретные вопросы:

Правильны ли мои убеждения, перечисленные выше? Является ли идея всегда использовать SPs чем-то, что является «старой школой» сейчас, когда ORM набирают популярность? По вашему опыту, какой лучший способ использовать EF - отображение SP для всех операций вставки / обновления / удаления или использование EF-сгенерированного SQL для операций CRUD и использование только SP для более сложных вещей?

Answer 1

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

Все мои основные операции CRUD являются прямым EF-сгенерированным кодом - мои веб-приложения раньше имели 100 или более SP, теперь типичное будет иметь дюжинуSP и все остальное сделано в моем коде на C # .... и моя производительность пошла ПУТЬ, удалив эти 95% хранимых процедур CRUD.

Answer 2

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

• База данных следует строгим правилам безопасности, где изменение данных разрешено только с помощью хранимых процедур
• Вы используете представления или пользовательские запросы для сопоставления ваших сущностей, и вам требуется расширенная логика в хранимой процедуре для возврата данных
• У вас есть некоторая продвинутая логика (связанная с данными) в процедуре по любой другой причине

Использование процедур для чистого CUD, где применяются не упомянутые выше случаи, является избыточным и не обеспечивает какого-либо ощутимого повышения производительности, за исключением одного сценария

• Вы будете использовать хранимые процедуры для пакетной / массовой модификации

EF не имеет функции групповой / пакетной обработки, поэтому изменение 1000 записей приводит к 1000 обновлениям, каждое из которых выполняется с отдельным циклом обращения к базе данных! Но такие процедуры не могут быть сопоставлены с сущностями в любом случае и должны выполняться отдельно через импорт функции (если возможно) или напрямую как ExecuteStoreCommand или старый ADO.NET (например, если вы хотите использовать параметр с табличным значением).

В CRUD может быть совсем другая история, где хранимая процедура может значительно повысить производительность при чтении данных с помощью ваших собственных оптимизированных запросов.

Answer 3

Если производительность является вашей главной задачей, то вы должны взять одно из ваших существующих приложений, использующих EF с SP, отключить SP и сравнить новую версию. Это единственный способ получить ответ, идеально подходящий для вашей ситуации. Возможно, вы обнаружите, что EF, независимо от того, что вы делаете, недостаточно быстр для удовлетворения ваших потребностей в производительности по сравнению с пользовательским кодом, но вне сайтов с очень большим объемом я думаю, что EF 4.1 на самом деле довольно разумный.

С моей точки зрения, EF - отличное повышение производительности труда разработчиков. Вы теряете значительную часть этого, если вы пишете SP для простых операций CRUD, и, в частности, для вставки / обновления / удаления, в действительности я не вижу, чтобы вы сильно выигрывали в производительности, потому что эти операции настолько просты для генерации SQL. Определенно, есть некоторые случаи Select, когда EF не будет работать оптимально, и вы можете значительно повысить производительность, написав SP (в качестве примера приводятся иерархические запросы с использованием CONNECT BY в Oracle).

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

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

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

Answer 4

Я полностью согласен с E.J, но есть несколько других вариантов. Это действительно сводится к требованиям для конкретной системы:

• Вам нужно, чтобы приложение было разработано БЫСТРО? - Тогда используйте Entity Framework и его автоматический SQL
• Нужна детальная и надежная защита? - Получить на хранимые процедуры
• Нужно ли бежать как можно быстрее? - Вы, наверное, смотрите на какую-то счастливую среду!

Answer 5

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