Денис Цветцих "Repository и UnitOfWork в 2020 году, must have или антипаттерн?"
HTML-код
- Опубликовано: 1 фев 2020
- Слайды: bit.ly/3b44IXk
Репозиторий - один из наиболее часто используемых паттернов для доступа к данным. Шло время, на смену ADO.NET пришел Entity Framework, вместо слоистой архитектуры все чаще используются Чистая архитектура и даже DDD, а вместо монолитов нередко встречаются микросервисы, но репозиторий все также актуален....
Постойте, или уже неактуален? В последнее время этот вопрос - тема для жарких дискуссий. Гуру разработки ПО, написавшие толстые книги, говорят, что репозиторий и UnitOfWork сегодня также актуальны, как и много лет назад. Но программисты-прагматики, между делом пишущие статьи в своих блогах, все чаще говорят о том, что сегодня эти паттерны уже реализованы в ORM и писать собственные реализации не нужно.
Я расскажу о том, какие есть реальные плюсы и минусы собственной реализации паттенов Repository и UnitOfWork в 2019 году. Вряд ли доклад поставит точку в дискуссиях, но даст противоборствующим сторонам пищу для размышлений.
![mgk - I Think I’m OKAY (with YUNGBLUD) (Sad Version) [Official Music Video]](http://i.ytimg.com/vi/7AC1uqQLIg4/mqdefault.jpg)
![Sean Rii, Karyon, Sharzkii - Taungule [My Love] (Official Music Video)](http://i.ytimg.com/vi/eJoMuypbSzQ/mqdefault.jpg)
Нет универсального решения. Проходил разные случаи:
1. Когда приходишь уже на работающий проект, то придется работать с тем, что уже написано, когда переписывать долго\дорого.
2. Когда делаешь стартап в условиях неизвестности и нужно быстрее показать MVP, подавляешь в себе внутреннего перфекциониста и программируешь чтобы просто работало (с мыслью о том, что 99% в будущем будем переписывать код, менять ORM, провайдера БД и т.д.)
3. Для небольших проектов на фрилансе зачастую вообще работал без репозиториев и UoW напрямую с ORM или БД.
Короче, пришел к выводу, что я скорее ЗА чем ПРОТИВ.
А разве при создании dbcontext в таблицах 1 к 1 нельзя настроить каскадное удаление? Через fluent настройку это делается в 1 строку кода. (32 минута)
Как-то тема не раскрыта, ни транзакций, ни сложных агрегатов.
Чтобы не писать все эти хендлеры для async листов не нужно вынимать из репозиториев iquerable. А сразу возврашать Task List пускай репозиторий сам этим занимается как умеет...
Блин, как же все это жизненно! Перелопатил несколько версий репозитория на проекте. Сейчас думаю, а не отказаться ли от него вообще. Есть здесь те люди, кто пришел из мира джавы? Мне интересно, там есть похожие муки выбора? Или просто берем хибернейт и напрямую используем в сервисах и контроллерах?
Думаю, что ситуация примерно такая же ) Например тут ruclips.net/video/LRJz0mHPfSc/видео.html говорится, что репозиторий нужен только если необходимо одновременно поддерживать несколько баз
@@DevBrothersPro А dbContext не вариант использовать с различными поставщиками данных?
@@Doctor.Livesey К сожалению, не вариант. EF.Functions будут разные для разных баз (типичный пример для MS SQL только один Like, а для Postgres два - регистрозависимый и независимый). Также raw sql, написанный для одной базы, может не сработать для другой. Так что как раз такие различия и будут прятаться в реализациях репозиториев для разных баз
UOF очень удобен при миграции с SQL на другие бд например mongodb.
Сложилось ощущение что автор видео сам себе сперва переусложнил жизнь а потом начал винить репозитории в этом. Молоток в неумелых руках будет больше по пальцам бить а не гвозди забивать. Если надо по быстрому запилить проект и в жизни ничего кроме SQL+EF не использовал то и репозиторий не нужен. (Правда в таком случае не факт что и агрегаторы, про которые тут упоминалось, нужны). Репозиторий хорош если уметь им пользоваться. Например данные планируется хранить в разных типах баз оптимизированных под разные типы операций (тут вот про CQRS упоминалось например но тема не расскрыта), другой хороший промер когда некоторые, а может и все данные надо еще и кешировать и тогда репозиторий например может скрывать не только доступ к базе но и доступ к кэшу. Не раскрыт вопрос удобства тестирования бизнес логики с ПРАВИЛЬНЫМ применением репозиториев, ну и конечно классический пример когда приходится (а у меня в практике такое было и не раз, хотя все же это редкий кейс) изменить тип базы данных.
Проблема лекции в том что UOF позиционировался как доступ к базе данных, что в корне не верно. UOF - это про доступ к данным. То есть это может быть доступ к данным что лежат на другом сервисе в микросервисной архитектуре, это может быть быть доступ к интернет ресурсам или неструктурированным локальным ресурсам (Как при реализации хранения файлов не в бд). Говорить о том что UOF ничего толком не решает говорит лиш о том, что автор такой мысли никогда не сталкивался с подобными кейсами.
Почему автор демонстрируя interface называет его реализацией?
Переложите пожалуйста слайды (у нас вк заблочен :( )
Смело. Но слишком категорично. Какой проект не посмотри, у всех своя правда и все привыкли работать с тем что есть. Люди ко многому приспосабливаются. Другое дело дизайн заложенный на начальном этапе, как стратегический акт, имеет длительное влияние на развитие и жизнь приложения. На этом этапе и решается вопрос необходимости абстракции. Решение зависит от многих факторов. Но если речь идёт об приложении которое является ядром бизнеса, то тут просто маст хев все эти абстрагирования. Да сложно, но как заклинание все шепчут - доменный слой не зависит от деталей. А репозиторий это абстракция, высокоуровневая абстракция которая соседствует или живёт вместе с доменом.
таки что предлагается, юзать дбконтекст прямо в контроллерах?
Интересно, но я ЗА свой репозиторий в проекте. Главная задача метода из репозитория - это принимать екземляр класса-фильтра и по его полям строить квериебл и експрешн - что угодно для дельныйшей обработки в EF и БД. Это позволит в одном месте изменить правила выборки и не бегать по всему проекту для поиска где-же эти запросы на дбсетах - их могут быть сотни и тысячи в сложном проекте. А так ты через один метод репозиотрия ходишь в БД и все ОК. Сто раз меня выручало. Но это все может быть испорчено, когда добавится еще один метод репозитория, который принимает експрешн и кверю в качетсве параметра - тут как бы все... приехали, репозиторий не то, чтобы протек, а него дно вывалилось.
Судя по всему путается паттерн Repository как он задумывался изначально, и Gateway (Repository вырождается в gateway повсеместно)
А чем Repository отличается от Gateway? И нужен ли этот репозиторий - в изначальном или вырожденном виде сейчас?
@@andrewtsvetsih2675 Так сразу сложно понять что где нужно, посмотрите Фаулера он ведь все это ввел, насколько я помню). Просто обычно достаточно Gateway и у Мартина он повсеместно используется. Это просто грубо говоря обертка над хранилищем - адаптер. Repository гораздо сложнее это уже хранилище объектов, а не просто адаптер.
А я думал, что листы используют только джуны или "старожилы". Но нет, и тут оно...
А чем вам лист не нравится? Работайте с ним как с интерфейсом. Там ведь все равно ToList() было при выборке из БД.
@@sergii7593 тем, что это сложный объект, управляющий списком. И задачи у него соответствующие. Это как минимум из разряда "из пушки по воробьям". Как максимум - дыра в данных. А посерединке ещё всякие там солиды и иже с ними болтаются.
разверните мысль?
@@anatoly-k А что тут разворачивать? Лист позволяет изменять данные в любой момент. Лист имеет сложную внутреннюю структуру и кучу «ненужных» методов. Лист - это ДИНАМИЧЕСКИЙ список. Зачем гонять память и открывать дыру в безопасности?
опять этого сумасшедшего из больницы выпустили
лютый плюс
зачем постоянно говорить "ВОТ" ?
Ну вот я прям не знаю... вот. 8)
Нашёл к чему придраться ...