EF inmemory?

вместо sql?

Не совсем понял вопроса, не вместо sql, а вместо базы

Инмемори это по сути целая готова реализация дб контекста без привязки к базе, да, он подойдёт для большинства случаев

вот это

да

дич

в ней нет поддержки транзакций

смотрю в сторону  efsqlite.inmemory

Я ин мемори только для тестов использовал

но эта вторая дич вытирается после обрыва коннекта

Но я всё равно считаю что лучше мокать все зависимости в едином стиле и работать с ними в едином стиле, тут generic repository лучше
К тому же, то что не отвалится при вставке туда, отвалится может при вставке через настоящий дбконтекст, а значит, это будет не так предсказуемо и тест будет казаться корректным
В случае мока можно проверять то что метод был вызван, мы не вызываем его по настоящему и потом не создаётся впечатления, что вставка удалась

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

А ну и при смене реализации DAL generic repository позволит не только общую абстракцию сохранить, а ещё и тесты останутся те же из-за этого

Не знаю как вам а мне тесты писать не особо нравится

Поэтому лично мне это весомый плюс

запарно оч, но пару фич очень полезные с ними получилось

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

от кастомного фасада для наполнения фейковой бд до наполнения реальной stage бд таким же способом