E
В описании есть ссылка на репозиторий с примером)
https://www.youtube.com/watch?v=MYXt_9d_2ps
https://www.youtube.com/watch?v=MYXt_9d_2ps
Size: a a a
2021 June 30
В
и вам спасибо)
В
1. Обычно предпочтительнее делить сначала по категориям функционала(фичам), а потом уже их делить на слои? Или это больше актуально при наличии в приложении большого количества разного функционала и, в противном случае, можно делать наоборот?
2. А всякие вспомогательные utils-функции разве не в core хранят?
2. А всякие вспомогательные utils-функции разве не в core хранят?
E
1. зависит от размера проекта и его развития) обычно, фичи -> слои
2. как кому удобно)
2. как кому удобно)
В
Спасибо. А можно еще кое-что у вас уточнить?
1. Если репозиторий не наследовать от интерфейса(который находится обычно в domain), то репозиторий все равно помещать в data или все же утащить его в domain?
2. Всякие DAO и Entity в data желательно держать?
1. Если репозиторий не наследовать от интерфейса(который находится обычно в domain), то репозиторий все равно помещать в data или все же утащить его в domain?
2. Всякие DAO и Entity в data желательно держать?
P
1. Репозиторий без интерфейса? А смысл? Репозиторий как раз и нужен, чтобы скрыть источники данных за интерфейсом. В интерфейсе репозитория используются модели domain. И сам интерфейс принадлежит domain. А имплементация - как раз принадлежит data. И там всякие dao, ретрофит и т.п. (отвечая на 2)
В
Хм, о вопросе сокрытия реализации я что-то не подумал. Благодарю)
VP
Репозиторий может быть без интерфейса, если нет необходимости подменять реализации. Ещё ни разу не встретил такой необходимости (не участвовал в проектах с большим покрытием тестов, где требовалось бы подменять репозитории)
ES
А интерфейс на уровне датасорса может быть? Допустим есть 3 разных метода получения одинаковых данных. Можно же выделить какой нить IDataSource и сделать 3 реализации его?
ES
у меня просто каждый месяц допиливается по 1 методу. И я просто в лист датасорсов добавляю еще один
ES
а сама репа уже вызывает их по очереди
В
А где вы в таком случае держите интерфейс? В data или domain?
P
Зависит от ситуации. Если domain не важны источники данных, то в domain может быть один интерфейс, а в имплементация уже рулит датасорсами
VP
У меня нет интерфейса для репозитория, нигде не держу)
E
интерфейса нет, а репозиторий лежит в data)
у нас тоже нет лишних интерфейсов ради интерфейсов)
у нас тоже нет лишних интерфейсов ради интерфейсов)
В
Тьфу, блин, ошибся. Я про репозиторий)
VP
Репозитории в data -> repositories
P
Получается, domain знает об имплементации репозитория. Не гуд.
В
Понял, пасиб)
В
Благодарю)