Конечно, по своей природе ORM призваны помочь держать всю бизнес-логику в самом приложении, а не в базе данных. В целом, этот подход лучше масштабируется, и, в придачу, позволяет меньшими усилиями сменить СУБД в случае сильного изменения требований к проекту.
Однако есть ряд задач, где триггеры вполне могут работать в паре с ORM-библиотекой. Это как раз таки НЕ бизнес-логика, а скорее support-логика. Сходу могу вспомнить следующее:
- поддержка целостности денормализованных данных - пересчет в триггере "избыточных" значений, например сумм, средних и т.д. (т.е. таких, которые всегда можно посчитать и которые хранят исключительно для повышения производительности запросов). В этом случае даже если кто-то захочет поработать с БД не пользуясь O/R маппингом (например, выполнить пару выборок для аналитики), не произойдет рассогласования данных;
- поддержка
хронологических и аудит-таблиц; это также логика, в общем-то не зависящая от предметной области, и зачастую она НЕ мапается в ORM-ке (особенно в случае аудит-таблиц - если с историей приложение еще может работать, то аудит как правило нужен лишь в исключительных случаях - повреждение данных, проблемы с безопасностью БД и т.д. - и запросы к таким таблицам делаются вручную в ходе исследования проблемы).
В EF с помощью
этого атрибута вы можете указывать, что значение свойства сущности генерируется самой БД и EF не должна участвовать в его обновлении.
