Когда использовать хранимые процедуры и запросы SQL в Entity Framework Code First

1

Каковы надлежащее использование хранимых процедур и SQL-запросов в коде EF-first, особенно в веб-разработке ASP.NET? Я сильно зависел от них, прежде чем я уставился на использование Entity Framework. Однако с Entity Framework, надеюсь, нам не нужно беспокоиться о написании SQL и создании хранимых процедур для создания, вставки, обновления и чтения данных и т.д.

Я знаю, что использование SQL может быть хорошим в некоторых случаях в EF, например, при очистке всей таблицы:

dbcontext.Database.ExecuteSqlCommand("delete from MyTable");

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

  • 0
    Это вопрос мнения, который не является темой для SO и поэтому, вероятно, будет закрыт. Мое мнение таково, что у вас есть ORM именно для абстракции, чтобы не использовать SQL, так что не надо.
  • 0
    @paqogomez где я должен опубликовать это?
Показать ещё 8 комментариев
Теги:
sql-server
stored-procedures
entity-framework

2 ответа

3
Лучший ответ

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

Некоторые примеры могут включать:

  • Операции BULK INSERT из загруженного пользователем файла в процесс
  • Рекурсивные КТО
  • Использование таблиц Temp/Table Variables для выполнения расширенной обработки
  • Использование существующих функций базы данных, procs, связанных серверов и т.д.
  • Экземпляры, в которых запросы достаточно продвинуты, что план запросов, сгенерированный с помощью ORM, является менее оптимальным, и вы знаете, что можете лучше работать с простым SQL. Кроме того, возможность использовать подсказки запросов в SQL является весьма полезной (хотя и редкостью)

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

Я бы не сказал, что любой ORM подходит для всех задач.

В какой-то степени я бы также предположил, что способность вашей команды DEV также поможет вам решить, что использовать где. Ваш ORM может быть прекрасным для простых запросов CRUD и полупрозрачного поиска. Однако для более сложной обработки, если ваша команда собирается потратить вдвое больше времени на то, чтобы что-то сделать в ORM, чем просто делать это в SQL, тогда вы должны спросить, хорошо ли это время и деньги.

  • 0
    Спасибо за объяснение! Я думаю, как независимый программист, разрабатывающий маломасштабные проекты, мне вряд ли понадобятся SP и SQL при использовании Entity Framework.
  • 0
    Возможно, это и так, но если вы много работаете с данными и базами данных, я бы настоятельно рекомендовал запачкать руки с помощью SQL (даже с помощью такого инструмента управления, как SSMS), чтобы вы могли принимать обоснованные решения относительно того, когда может быть более полезным по сравнению с другим.
Показать ещё 1 комментарий
2

Очень редко (<0,1%) у вас будет случай использовать хранимые procs, в остальном 99,9% вы должны использовать ORM или сущность framework в вашем случае.

Вот несколько примеров, которые я использовал хранимые procs.

i) Полнотекстовый поиск, такой как Google, с такими сложными требованиями, как поиск близости, прерыватель слов, стволовые клетки, INFLECTIONAL и т.д.

ii) Включение некоторых столбцов таблицы зашифровано, и у вас есть запросы с этими столбцами в условных операторах.

iii) Для миграции базы данных в базу данных, работы sql и т.д.

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

  • 0
    спасибо за примеры pjobs!

Ещё вопросы

Сообщество Overcoder
Наверх
Меню