сошлись не на жизнь а насмерть по поводу его сути.
Я говорю, что репозиторий - это прежде всего ИНТЕРФЕЙС который содержит набор методов и работает с domain-сущностями. И есть куча его реализаций в зависимости от источника данных. В вьюмодели прокидывается именно интерфейс, а конкретная реализация выбирается нами через DI. Соответственно для каждого источника данных существуют свои мапперы сущностей из понятных им до domain-сущностей.
Товарищ у меня говорит, что репозиторий содержит в себе все возможные источники данных и все методы работы с этими источниками и мы просто в определенный момент выбираем какой из методов вызвать.
Как по мне нахер тогда вообще нужен репозиторий если он будет являться просто огромной свалкой для работы с data-слоем. И полиморфизма я тоже не наблюдаю при такой схеме. Рассудите пожалуйста, а то работа уже 2 часа стоит)
не всегда возможно сделать интерфейс репозитория таким же, как у источников данных. Например иногда вам может захотеться достать данные однозначно свежие, а иногда вы можете спокойно положиться на кэширование. У меня репозиторий это обычно штука которая за одним удобным интерфейсом (с доменными моделями, разумеется), прячет работу с одним или несколькими источниками данных. Насколько она умная внутри - зависит от конкретной ситуации. Вы не найдёте Истину В Последней Инстанции в этом вопросе) Обсудите конкретные плюсы и минусы в вашей ситуации, и примите какой-то консистентный подход в проекте.
Репозиторий это фасад для работы с данными он выбирает какой источник взять чтобы сделать необходимое по запросу бизнес-логики (подготовить для нее данные или распределить данные от нее) , ViewModel или Domain если таковой есть . Реализация репозитория може быть в data слое может быть отдельным слоем gateway .Что точно ,так это то, что репозиторий не может быть в domain слое реализован ,там может быть лишь его контракт (интерфейс)
+++ Спасибо! Благодаря вашим ответам получается собрать очень хорошую картину в голове! Благодарю!
Репозиторий - это репозиторий. Фасад - это фасад. Это два разных паттерна.
Как Вы отличаете репозиторий от фасада?
Можно узнать почему репозиторий не может быть реализован в домеин(кор) слое?
Потому ,что репозиторий это менеджер данных .Он ответственный за подготовку данных или распределением ,своего рода проводник в источники, который не хранит состояние. У него может попросить дать данные или отправить ViewModel ,но ViewModel не должна вызывать его методы напрямую это чревато развитию высокой связанности,может негативно сказаться на масштабировании продукта .Чтобы этого избежать нужно использовать контракт через который ViewModel может общаться с Repository . Если бизнес логика вынесена в Domain,то тут работает все точно так же только ещё строже, контракт располагается в domain для вызова этого самого проводника ,но кто им будет его это не должно волновать .В любом случае бизнес-логики не должна ничего знать о данных ,оно работает с тем что ей дают.Потому что ее зона ответственности. Модели не должны записывать данные в базу или вызывать API сервера.Точно так же как детектор завода не должен выполнять работу сварщика, слесаря, мастера цеха - иначе будет хаос.У каждого своя зона ответственности должна быть.
кстати, почему именно фасад, а не, например, медиатор или прокси? Никогда не понимал четкой границы между этими шаблонами
Ну смотрите на уровне системы Repository может выполнять роль реализации паттерна mediator ,но на уровне самой имплиментации этого mediator он уже как facade ,грубо говоря mediator больше архитектурный паттерн в то время как facade уже его дополняет ,в роли прокси становятся провайдеры
Обсуждают сегодня