Телеграмм чат группы Android_Architecture страница 4503

Чем Repository отличается от DataSource тогда?

DAO 😀

14:01пожаловаться #1

Pavel

Тогда это лучше назвать не репозиторий, а как-то типа DataSource. И оно будет принадлежать слою бизнес-логики.
Репозитории лучше держать чистыми. Т.к. возможна ситуация, когда вся эта логика кеширования не нужна будет каким-то интеракторам, либо нужна будет другая.

Разве не DataSource отвечает за получение данных из одного источника данных?

14:01пожаловаться #2

Чем Repository отличается от DataSource тогда?

датасорс не нужон
репозиторий - нужон, если хочешь выделить бизнес в отдельный java-модуль

14:01пожаловаться #3

Pavel in Android Architecture

Репозиторий - чистая оберка над данными, DataSource - может объединять репозитории.

14:01пожаловаться #4

датасорс не нужон
репозиторий - нужон, если хочешь выделить бизнес в отдельный java-модуль

если у вас репозиторий это дао тогда ...

14:01пожаловаться #5

Pavel

Репозиторий - чистая оберка над данными, DataSource - может объединять репозитории.

а я думал что репозиторий объединяет датасорсы

14:02пожаловаться #6

Pavel in Android Architecture

Разве не DataSource отвечает за получение данных из одного источника данных?

Ну, хз как лучше назвать. Может не DataSource, а таки интерактор. Главное, что оно слою бизнес-логики принадлежит

14:02пожаловаться #7

Максим

а я думал что репозиторий объединяет датасорсы

Аналогично считал
Google частенько продвигал такое же видение

14:02пожаловаться #8

Максим

если у вас репозиторий это дао тогда ...

RoomDAO, RetrofitAPI = репозиторий с компромиссом на аннотации

14:02пожаловаться #9

Pavel

Ну, хз как лучше назвать. Может не DataSource, а таки интерактор. Главное, что оно слою бизнес-логики принадлежит

Получение данных - это бизнес-логика?

14:03пожаловаться #10

Pavel in Android Architecture

Обработка. Получением занимается репозиторий.

14:03пожаловаться #11

если есть логика репозитория по получению данных, то можно сделать ему датасорсы, а если нет такой логики, и это решает интерактор - то пусть он сам и работает с датасорсами, не так?

14:03пожаловаться #12

RoomDAO, RetrofitAPI = репозиторий с компромиссом на аннотации

Мне казалось, что это как раз чистые DAO

14:03пожаловаться #13

Получение данных - это бизнес-логика?

что такое получение данных?
интерфейс репозитория относится к бизнес-слою
реализация - к слою данных

Roman Chumachenko in Android Architecture

14:03пожаловаться #14

RoomDAO, RetrofitAPI = репозиторий с компромиссом на аннотации

Ну такое. Сегодня у тебя рум, завтра вы меняете все на realm и нужно избавляться от зависимостей в корень. Сидишь, выпиливаешь кучу аннотаций и иже с ними

14:04пожаловаться #15

Мне казалось, что это как раз чистые DAO

очень показательно в Spring Boot реализовано
у них есть репозитории и есть сервисы для бизнес логики
это отлично работает

14:04пожаловаться #16

что такое получение данных?
интерфейс репозитория относится к бизнес-слою
реализация - к слою данных

Тут не редко начинает проскакивать мысль, что Repository не нужен, интерактор может работать с DataSource напрямую
Поэтому задал такой вопрос

14:04пожаловаться #17

Roman Chumachenko

интерфейс рум можно реализовать через realm, какие проблемы?

Roman Chumachenko in Android Architecture

14:04пожаловаться #18

интерфейс рум можно реализовать через realm, какие проблемы?

Еще раз - ты будешь менять файл с интерфейсом, чтобы убрать все упоминания рума, потому что зависимость нужно убрать из проекта

14:05пожаловаться #19

хз, чо такое датасорс по сравнению с репозиторием, какая-то надуманная сущность
думаю, что может, т.к. ds ~ repository