Переопределить поведение в Entity Framework

Question

У нас есть модель данных, которая имеет некоторые требования. Я хотел бы найти способ сделать эти требования максимально прозрачными при использовании EF.

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

Во-вторых, у нас есть политика «только вставка». Это означает, что нет обновлений. Когда обновление сделано, новая запись должна быть вставлена ​​взамен. Я хотел бы иметь возможность обрабатывать операцию как обновление, и сделать так, чтобы фреймворк заменил ее вставкой за кулисы.

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

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

Кто-нибудь реализовывал такую ​​модель данных в EF? Какие техники вы использовали?

Мне известно, что это можно сделать в представлениях и / или Sprocs, но если вы используете представления, вам придется поддерживать все отношения вручную (EF не может прочитать отношения через представления). Триггеры также возможны, но наши администраторы баз данных хотят иметь как можно меньше триггеров и имеют очень обширную политику проверки всех триггеров, выполнение которой занимает много времени. Я бы предпочел не использовать триггер, если мне не нужно.

Я работаю в основном с базой данных, но я использую dbcontext.

EDIT:

Учитывая комментарии Ладислава ниже, мне также будут интересны любые комментарии о других ORM, которые могут удовлетворить эти требования.

Answer 1

1. Это возможно при условном отображении, где дополнительный столбец будет использоваться для различения удаленных записей, и настраиваемая команда SQL / сопоставленная хранимая процедура для каждого объекта, требующего мягкого удаления для выполнения обновления вместо удаления.
2. Я сомневаюсь, что EF справится с этим прозрачно. Если вы измените вложенный экземпляр, загруженный из базы данных, он выполнит обновление. Вы можете снова отобразить хранимую процедуру для выполнения вставки вместо обновления, но это изменение не будет отражено в логике вашего приложения. Вам нужно будет удалить контекст и перезагрузить данные с новым экземпляром контекста, чтобы правильно увидеть изменения. Лучший вариант - просто заставить ваше приложение где-нибудь клонировать сущность и вставить клон как новый.
3. EF не позволит вам прозрачно добавить такое условие к автоматически сгенерированным запросам, если вы не отобразите его как представление или пользовательский запрос SQL . Когда вы используете представление или запрос SQL, вы также должны использовать команды SQL или хранимые процедуры из операций вставки, обновления и удаления. Использование пользовательского SQL-запроса имеет те же недостатки, что и использование представлений.
4. Если вы не используете SQL-запрос, вам придется написать запрос самостоятельно, например, в форме настраиваемого метода расширения многократного использования и использовать его везде, но имейте в виду, что энергичная или ленивая загрузка не будет отражать это. В случае быстрой и ленивой загрузки вы всегда получите все версии.

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