Есть ли преимущество переопределения запросов вставки / обновления / удаления по умолчанию для EF

Question

Поскольку вопрос действительно задан.

Инструмент моделирования EF позволяет нам сопоставить функции вставки / обновления / удаления с sproc, есть ли какое-то преимущество в их переопределении?

Если этотребует некоторой пользовательской проверки, тогда, очевидно, да, но если я доволен тем, как оно сейчас, стоит ли создавать sproc для них всех?

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

Answer 1

Я могу вспомнить несколько случаев, когда это может быть полезно:

• Вы работаете с устаревшей базой данных, которая не совсем точно соответствует вашей модели EF.
• Вам нужно выполнить дополнительные запросы при вставке / обновлении / удалении, но у вас нет прав на триггеры в вашей базе данных.
• Софт удаляет в вашей базе данных, что вы хотите абстрагироваться от. Таким образом, обычное удаление фактически выполняет мягкое удаление.

Не совсем уверен, насколько жизнеспособны эти варианты, так как лично я скорее парень из NHibernate. Это теоретические варианты.

Что касается просмотра выполненных запросов, есть несколько возможностей сделать это. Вы можете присоединить профилировщик к вашему экземпляру SQL Server и посмотреть на необработанные запросы, которые выполняются. Существует также Entity Framework Profiler (автор Ayende / Oren Eini), который не является бесплатным, но он значительно облегчает чтение и отладку запросов.

Answer 2

Да. Есть преимущество в их переопределении.

Не все фактически обновляют или удаляют строку данных, когда происходит обновление или удаление.

В некоторых случаях удаление записи действительно означает установку даты EffictiveUntil для существующей записи и сохранение записи в базе данных для исторических целей.

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

Предоставляя логику вставки / обновления / удаления для Entity Framework, вы можете точно указать, что эти операции означают в терминах вашей базы данных, а не то, что они означают в рамках СУБД.

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