НП
хочу кверики, а не дбСеты и прочую стандартную лабуду, которая из коробки идет в хибере
Size: a a a
2020 August 04
АМ
Накручивать поверх EF еще и репозиторий мне кажется не целесообразно
НП
Андрей Мацко
Накручивать поверх EF еще и репозиторий мне кажется не целесообразно
А целый контекст передавать это огонь? Или есть другое решение?
АМ
куда передавать?
НП
Андрей Мацко
куда передавать?
в те классы, где нужны данные
S
а контекст как тестировать?
S
бизнес логику по выборке, фильтрации?
AN
ну не репозиторий, а контекст
контекст не репозиторий а unit of work
dbset репозиторий
dbset репозиторий
НП
контекст не репозиторий а unit of work
dbset репозиторий
dbset репозиторий
Но явно передавать контекст, это вообще зло, как по мне
АМ
аргументируй, почему зло?
НП
Андрей Мацко
аргументируй, почему зло?
Как ты будешь потом юнит тесты писать на классы, где данные юзаются?
AN
Андрей Мацко
Накручивать поверх EF еще и репозиторий мне кажется не целесообразно
а как ты будешь тестировать все что не крад?
АМ
я смотрю вы прям все тестировщики
S
да и мешать логику потом тоже такое себе .
Например есть у тебя контроллер.
В нем ты будешь писать типа context.Where(x=> /// ) .ToList()
Например есть у тебя контроллер.
В нем ты будешь писать типа context.Where(x=> /// ) .ToList()
S
это мешанина и нарушение уже SRP
AN
Андрей Мацко
я смотрю вы прям все тестировщики
ну если продолжать аналогию, то ты юморист
вот пошутил же )
вот пошутил же )
НП
Андрей Мацко
я смотрю вы прям все тестировщики
Окей, какой смысл работать с конкретной реализацией? А вдруг вы захотите потом отвязываться от EF? Весь проект перепахивать?
S
Проще сделать класс который занимается data manipulation
S
его и тестировать уже в отрыве от бд
S
такой класс и есть repository