Денис Цветцих "Repository и UnitOfWork в 2020 году, must have или антипаттерн?"

[@alekseev74]

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

[@bananasba]

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

[@artursveshnikov7668]

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

[@romantitov6207]

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

[@ruslanra2356]

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

[@musicslime2888]

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

[@ruslanra2356]

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

[@monklg]

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

[@ИванИванов-я5э9к]

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

[@DevBrothersPro]

Думаю, что ситуация примерно такая же ) Например тут kzbin.info/www/bejne/goOtq2OjfbWZicU говорится, что репозиторий нужен только если необходимо одновременно поддерживать несколько баз

[@Doctor.Livesey]

@@DevBrothersPro А dbContext не вариант использовать с различными поставщиками данных?

[@DevBrothersPro]

@@Doctor.Livesey К сожалению, не вариант. EF.Functions будут разные для разных баз (типичный пример для MS SQL только один Like, а для Postgres два - регистрозависимый и независимый). Также raw sql, написанный для одной базы, может не сработать для другой. Так что как раз такие различия и будут прятаться в реализациях репозиториев для разных баз

[@AlexeyLopatin-m4r]

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

[@sergii7593]

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

[@anatoly-k]

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

[@vovcheable]

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

[@DarDarbl4]

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

[@andrewtsvetsih2675]

А чем Repository отличается от Gateway? И нужен ли этот репозиторий - в изначальном или вырожденном виде сейчас?

[@DarDarbl4]

@@andrewtsvetsih2675 Так сразу сложно понять что где нужно, посмотрите Фаулера он ведь все это ввел, насколько я помню). Просто обычно достаточно Gateway и у Мартина он повсеместно используется. Это просто грубо говоря обертка над хранилищем - адаптер. Repository гораздо сложнее это уже хранилище объектов, а не просто адаптер.

[@angryshiba5015]

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

[@ДмитрийК-н7и]

лютый плюс

[@WoulDoar]

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

[@sergii7593]

А чем вам лист не нравится? Работайте с ним как с интерфейсом. Там ведь все равно ToList() было при выборке из БД.

[@WoulDoar]

@@sergii7593 тем, что это сложный объект, управляющий списком. И задачи у него соответствующие. Это как минимум из разряда "из пушки по воробьям". Как максимум - дыра в данных. А посерединке ещё всякие там солиды и иже с ними болтаются.

[@anatoly-k]

разверните мысль?

[@WoulDoar]

@@anatoly-k А что тут разворачивать? Лист позволяет изменять данные в любой момент. Лист имеет сложную внутреннюю структуру и кучу «ненужных» методов. Лист - это ДИНАМИЧЕСКИЙ список. Зачем гонять память и открывать дыру в безопасности?

[@askolit1458]

Ели коротко: бегаем, решаем проблемы, которых даже не существует, в надежде, что, когда-то там, они возникнут, а код их уже решает. Почему-то все пытаются впихнуть паттерны просто с нуля, хотя они, по сути, никакой проблемы не решают вообще. Нужно сначала написать код, а потом, если в этом есть нужда, применить паттерны, тогда даже в истории будет видно какую именно проблему решили таким сбособом, иначе это просто натягивание совы на глобус. Тоже самое и с DI, все привыкли делать миллиард интерфейсов, у которых только 1 реализация, хотя интерфейсы нужно создавать тогда, когда в проекте явно есть несколько реализаций чего-то схожего, только тогда вы сможете высказать свой любимый аргумент: "это упрощает тестирование".

[@dmitry8386]

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

[@sergbo3114]

Ну вот я прям не знаю... вот. 8)

[@СергейДовгалев-р5я]

Нашёл к чему придраться ...