Нет универсального решения. Проходил разные случаи: 1. Когда приходишь уже на работающий проект, то придется работать с тем, что уже написано, когда переписывать долго\дорого. 2. Когда делаешь стартап в условиях неизвестности и нужно быстрее показать MVP, подавляешь в себе внутреннего перфекциониста и программируешь чтобы просто работало (с мыслью о том, что 99% в будущем будем переписывать код, менять ORM, провайдера БД и т.д.) 3. Для небольших проектов на фрилансе зачастую вообще работал без репозиториев и UoW напрямую с ORM или БД. Короче, пришел к выводу, что я скорее ЗА чем ПРОТИВ.

А разве при создании dbcontext в таблицах 1 к 1 нельзя настроить каскадное удаление? Через fluent настройку это делается в 1 строку кода. (32 минута)

Как-то тема не раскрыта, ни транзакций, ни сложных агрегатов.

UOF очень удобен при миграции с SQL на другие бд например mongodb.

Блин, как же все это жизненно! Перелопатил несколько версий репозитория на проекте. Сейчас думаю, а не отказаться ли от него вообще. Есть здесь те люди, кто пришел из мира джавы? Мне интересно, там есть похожие муки выбора? Или просто берем хибернейт и напрямую используем в сервисах и контроллерах?

Чтобы не писать все эти хендлеры для async листов не нужно вынимать из репозиториев iquerable. А сразу возврашать Task List пускай репозиторий сам этим занимается как умеет...

Переложите пожалуйста слайды (у нас вк заблочен :( )

Сложилось ощущение что автор видео сам себе сперва переусложнил жизнь а потом начал винить репозитории в этом. Молоток в неумелых руках будет больше по пальцам бить а не гвозди забивать. Если надо по быстрому запилить проект и в жизни ничего кроме SQL+EF не использовал то и репозиторий не нужен. (Правда в таком случае не факт что и агрегаторы, про которые тут упоминалось, нужны). Репозиторий хорош если уметь им пользоваться. Например данные планируется хранить в разных типах баз оптимизированных под разные типы операций (тут вот про CQRS упоминалось например но тема не расскрыта), другой хороший промер когда некоторые, а может и все данные надо еще и кешировать и тогда репозиторий например может скрывать не только доступ к базе но и доступ к кэшу. Не раскрыт вопрос удобства тестирования бизнес логики с ПРАВИЛЬНЫМ применением репозиториев, ну и конечно классический пример когда приходится (а у меня в практике такое было и не раз, хотя все же это редкий кейс) изменить тип базы данных.

таки что предлагается, юзать дбконтекст прямо в контроллерах?

Почему автор демонстрируя interface называет его реализацией?

Смело. Но слишком категорично. Какой проект не посмотри, у всех своя правда и все привыкли работать с тем что есть. Люди ко многому приспосабливаются. Другое дело дизайн заложенный на начальном этапе, как стратегический акт, имеет длительное влияние на развитие и жизнь приложения. На этом этапе и решается вопрос необходимости абстракции. Решение зависит от многих факторов. Но если речь идёт об приложении которое является ядром бизнеса, то тут просто маст хев все эти абстрагирования. Да сложно, но как заклинание все шепчут - доменный слой не зависит от деталей. А репозиторий это абстракция, высокоуровневая абстракция которая соседствует или живёт вместе с доменом.

Проблема лекции в том что UOF позиционировался как доступ к базе данных, что в корне не верно. UOF - это про доступ к данным. То есть это может быть доступ к данным что лежат на другом сервисе в микросервисной архитектуре, это может быть быть доступ к интернет ресурсам или неструктурированным локальным ресурсам (Как при реализации хранения файлов не в бд). Говорить о том что UOF ничего толком не решает говорит лиш о том, что автор такой мысли никогда не сталкивался с подобными кейсами.

Интересно, но я ЗА свой репозиторий в проекте. Главная задача метода из репозитория - это принимать екземляр класса-фильтра и по его полям строить квериебл и експрешн - что угодно для дельныйшей обработки в EF и БД. Это позволит в одном месте изменить правила выборки и не бегать по всему проекту для поиска где-же эти запросы на дбсетах - их могут быть сотни и тысячи в сложном проекте. А так ты через один метод репозиотрия ходишь в БД и все ОК. Сто раз меня выручало. Но это все может быть испорчено, когда добавится еще один метод репозитория, который принимает експрешн и кверю в качетсве параметра - тут как бы все... приехали, репозиторий не то, чтобы протек, а него дно вывалилось.

Судя по всему путается паттерн Repository как он задумывался изначально, и Gateway (Repository вырождается в gateway повсеместно)

А я думал, что листы используют только джуны или "старожилы". Но нет, и тут оно...

опять этого сумасшедшего из больницы выпустили

зачем постоянно говорить "ВОТ" ?