Kd
onAttachToWindow ченить такое, не?
Size: a a a
2020 September 16
Kd
в самом адаптере
АП
Всем привет. Подскажите пожалуйста, на какие модули следует разделить приложение, чтобы добиться clean architecture.
Модули на фичи делать не собираюсь..
Пока вижу следующие модули
app
common
domain
repository
Модули на фичи делать не собираюсь..
Пока вижу следующие модули
app
common
domain
repository
АП
Наверное лучше data, а не repository
АЕ
Можно и вообще без модулей добиться
АП
Но в некоторых проектах встречал модуль и data и repository
АП
Можно и вообще без модулей добиться
Хотелось бы с модулями
АП
И если у кого-нибудь пример на github, я был бы очень благодарен за ссылку
АЕ
По чатику поищите тоже, накидывали уже ссылок
АП
Спасибо, буду искать
GK
Анатолий Петров
Всем привет. Подскажите пожалуйста, на какие модули следует разделить приложение, чтобы добиться clean architecture.
Модули на фичи делать не собираюсь..
Пока вижу следующие модули
app
common
domain
repository
Модули на фичи делать не собираюсь..
Пока вижу следующие модули
app
common
domain
repository
app (presenters impl, interactors)
domain (models, usecases, repository interfaces, presenter interfaces)
repository (repositories impls, local storages interfaces, remote storages interfaces)
local (local storages impls)
remote (server api, remote storages impls)
domain (models, usecases, repository interfaces, presenter interfaces)
repository (repositories impls, local storages interfaces, remote storages interfaces)
local (local storages impls)
remote (server api, remote storages impls)
АП
Gen K
app (presenters impl, interactors)
domain (models, usecases, repository interfaces, presenter interfaces)
repository (repositories impls, local storages interfaces, remote storages interfaces)
local (local storages impls)
remote (server api, remote storages impls)
domain (models, usecases, repository interfaces, presenter interfaces)
repository (repositories impls, local storages interfaces, remote storages interfaces)
local (local storages impls)
remote (server api, remote storages impls)
👍
АП
Спасибо
АП
Можете пояснить назначение интеракторов?
АП
Чем они отличаются от usecase?
АП
Gen K
app (presenters impl, interactors)
domain (models, usecases, repository interfaces, presenter interfaces)
repository (repositories impls, local storages interfaces, remote storages interfaces)
local (local storages impls)
remote (server api, remote storages impls)
domain (models, usecases, repository interfaces, presenter interfaces)
repository (repositories impls, local storages interfaces, remote storages interfaces)
local (local storages impls)
remote (server api, remote storages impls)
А local и remote это отдельные уровни?
АП
Gen K
app (presenters impl, interactors)
domain (models, usecases, repository interfaces, presenter interfaces)
repository (repositories impls, local storages interfaces, remote storages interfaces)
local (local storages impls)
remote (server api, remote storages impls)
domain (models, usecases, repository interfaces, presenter interfaces)
repository (repositories impls, local storages interfaces, remote storages interfaces)
local (local storages impls)
remote (server api, remote storages impls)
Реализация репозитория должна быть в модуле domain? А модели в domain это модели, которые будут выводиться в ui?
GK
Я usecase делаю "плоскими", без асинхронщины. Такие классы много легче писать по TDD, да и просто покрывать тестами. Интерактор - это по факту фасад над usecase, который берет на себя асинхронщину. Это его единственная ответственность.
Репозиторий - это гейт между бэком, локальным хранилищем и ядром (domain). UseCase обращается к repository, не задумываясь о том, откуда/куда брать/отдавать данные. Соответственно в слое domain у тебя интерфейс репозитория. Реализация репозитория - в слое репозиториев.
Репозиторий разруливает потоки данных. Если нет данных, обращается к интерфейсу remote storage. Если нужно кэшировать, сохраняет полученные с бэка в локальное хранилище (через интерфейсы локальных хранилищ). Если данные уже есть в локальном хранилище, берет их оттуда через интерфейсы локальных хранилищ. Соответственно в слое репозиториев нужно знать интерфейсы локальных и удаленных хранилищ. А вот их реализации создаются в слоях local и remote.
Что это дает? Если к примеру решили перейти на другую БД, переписывание модуля local не затронет модули remote и repository. Соответственно компилятору нет нужды перекомпилировать остальные модули.
Репозиторий - это гейт между бэком, локальным хранилищем и ядром (domain). UseCase обращается к repository, не задумываясь о том, откуда/куда брать/отдавать данные. Соответственно в слое domain у тебя интерфейс репозитория. Реализация репозитория - в слое репозиториев.
Репозиторий разруливает потоки данных. Если нет данных, обращается к интерфейсу remote storage. Если нужно кэшировать, сохраняет полученные с бэка в локальное хранилище (через интерфейсы локальных хранилищ). Если данные уже есть в локальном хранилище, берет их оттуда через интерфейсы локальных хранилищ. Соответственно в слое репозиториев нужно знать интерфейсы локальных и удаленных хранилищ. А вот их реализации создаются в слоях local и remote.
Что это дает? Если к примеру решили перейти на другую БД, переписывание модуля local не затронет модули remote и repository. Соответственно компилятору нет нужды перекомпилировать остальные модули.
AT
Анатолий Петров
Чем они отличаются от usecase?
https://telegra.ph/Android-Architecture-06-02
здесь есть ответы на все ваши вопросы
здесь есть ответы на все ваши вопросы
А
Анатолий Петров
Хотелось бы с модулями
"Хотелось бы" без практического опыта звучит как-то странно