А
В то время как более опытные коллеги не советуют этого делать
Size: a a a
2020 September 16
GK
В domain модель - это максимально очищенная от фреймворков модель. В UI возможно будет необходим мапинг модели в UI-представление. К примеру в модели у тебя enum состояний (waiting, in_process, done). А в UI - ты будешь выводить уже текстовое или какое другое представление этих enum, к примеру, плюс локализация здесь же.
S
Есть экран
Есть экран
И экран
Как будет схематично выглядеть иерархия модулей???
Авторизации из 5 модулей, 1 из модулей будет вызван в дальнейшем.Есть экран
Настроек из 3 модулей, который использует также 1 модуль из АвторизацииИ экран
Главное, который использует модуль НастроекАвторизация->Главное->Настройки->подМодуль АвторизацииКак будет схематично выглядеть иерархия модулей???
S
Создаем модуль авторизации, внутри него 5 модулей? или каждый модуль создавать отдельно? Называя их auth_1 auth_2...
на название не смотрите, это пример
на название не смотрите, это пример
АП
В то время как более опытные коллеги не советуют этого делать
В приложении, которое мне досталось уже есть разделение, так что я не особо свободен в этом направлении
АП
Gen K
Я 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. Соответственно компилятору нет нужды перекомпилировать остальные модули.
Спасибо за подробный ответ, очень доходчиво! С репозиторием я всегда так делал. А вот с usecase и interact не до конца понимаю.. interact оборачивает usecase с элементом асинхронности? А interact может содержать несколько usecase? К примеру, получение данных из репозитория, нужно сперва посмотреть их в кэше, потом в базе, потом запросить их по http. Можете на этом примере пояснить, как это будет с intecart и usecase?
АП
Gen K
В domain модель - это максимально очищенная от фреймворков модель. В UI возможно будет необходим мапинг модели в UI-представление. К примеру в модели у тебя enum состояний (waiting, in_process, done). А в UI - ты будешь выводить уже текстовое или какое другое представление этих enum, к примеру, плюс локализация здесь же.
Т е маппинг в ui представление будет в ui уровне? Не на уровне domain?
GK
Анатолий Петров
Т е маппинг в ui представление будет в ui уровне? Не на уровне domain?
Конечно в UI. Ты же только в UI оперируешь цветами, картинками, локализованными текстами. В domain - только их "абстрактные представления": енумы и т.п.
GK
Приведи пример usecas'ов. Я набросаю черновик.
АП
Gen K
Конечно в UI. Ты же только в UI оперируешь цветами, картинками, локализованными текстами. В domain - только их "абстрактные представления": енумы и т.п.
Хорошо, т.е. domain мне вернёт сущности уровня data (вместе с аннотациями Room и прочими) и я их на уровне app (UI) перегоняю в сущности для UI? Т е мне нужен один маппер? Между repository и data никаких DTO не требуется?
GK
Мы в domain шелуху фреймворков не допускаем. Соответственно никаких Room и прочего, только голые данные. Очистка от шелухи Room происходит на уровне локального хранилища. Очистка от шелухи Gson происходит на уровне remote storage.
S
Singular
Есть экран
Есть экран
И экран
Как будет схематично выглядеть иерархия модулей???
Авторизации из 5 модулей, 1 из модулей будет вызван в дальнейшем.Есть экран
Настроек из 3 модулей, который использует также 1 модуль из АвторизацииИ экран
Главное, который использует модуль НастроекАвторизация->Главное->Настройки->подМодуль АвторизацииКак будет схематично выглядеть иерархия модулей???
Help
АП
Gen K
Приведи пример usecas'ов. Я набросаю черновик.
А тот пример, который я описал с получением данных, не подойдёт?
AD
Singular
Help
а зачем тебе на модули делить?
АП
Gen K
Мы в domain шелуху фреймворков не допускаем. Соответственно никаких Room и прочего, только голые данные. Очистка от шелухи Room происходит на уровне локального хранилища. Очистка от шелухи Gson происходит на уровне remote storage.
Я немного сбился... что подразумевается под local и remote storage? Понял) это база и api. Т е storage возвращает очищенные объекты. Это всегда делается? В таком случае придётся маппить все объекты, которые получаем из storage, не накладно ли это и оправдано?
A
Анатолий Петров
Я немного сбился... что подразумевается под local и remote storage? Понял) это база и api. Т е storage возвращает очищенные объекты. Это всегда делается? В таком случае придётся маппить все объекты, которые получаем из storage, не накладно ли это и оправдано?
всегда нужен чем-то жертвовать, маппинг в данном случае будет как раз той самой жертвой
при смене ответа сервера ты поменяешь только дата класс ответа и маппер и не будешь ковыряться в репозитории и не дай бог в юи
при смене ответа сервера ты поменяешь только дата класс ответа и маппер и не будешь ковыряться в репозитории и не дай бог в юи
GK
Анатолий Петров
А тот пример, который я описал с получением данных, не подойдёт?
Твой пример - это ответственность репозитория. UseCase вообще не парит откуда пришли данные. Он обращается к репозиторию "дай данные" и все. Опиши какую-нибудь несложную бизнесовую логику, распишу ее по классам.
S
а зачем тебе на модули делить?
В проекте работаем в 5, надо делить
АП
Gen K
Твой пример - это ответственность репозитория. UseCase вообще не парит откуда пришли данные. Он обращается к репозиторию "дай данные" и все. Опиши какую-нибудь несложную бизнесовую логику, распишу ее по классам.
К примеру, аутентификация пользователя:
Нужно проверить логин на корректность
Потом отправить на сервер
Если получилось пройти аутентификацию, нужно обновить значения в базе и перейти в другое activity
Если не прошли аутентификацию, тогда нужно сообщить об этом пользователю
Нужно проверить логин на корректность
Потом отправить на сервер
Если получилось пройти аутентификацию, нужно обновить значения в базе и перейти в другое activity
Если не прошли аутентификацию, тогда нужно сообщить об этом пользователю
АП
Gen K
Твой пример - это ответственность репозитория. UseCase вообще не парит откуда пришли данные. Он обращается к репозиторию "дай данные" и все. Опиши какую-нибудь несложную бизнесовую логику, распишу ее по классам.
Т е абсолютно все, что связано с получаем и агрегированием данных мне нужно держать в репозитории? Т е будут отдельные методы в репозитории, такие как проверка в кэше, проверка в базе, если есть, тогда отдавать с первого источника?