Size: a a a

Android Architecture

2020 May 28

R

Roman K. in Android Architecture
Маппировать - до передачи в UseCase, ещё в дата слое.
Если делать маппинг в UseCase, то получается, что он зависит от DTO из запроса
источник

PA

Pavel Aleksandrov in Android Architecture
То есть, получается такая цепочка: Данные Из View --> ViewModel/Presenter (если они нужны). Здесь они превращаются в промежуточный объект для UseCase. --> UseCase --> Repository. Здесь данные превращаются в объект для IO. --> IO.

Ответ: IO --> Repository. Здесь данные превращаются в бизнес-объект. --> UseCase. Здесь данные превращаются в объект для ViewModel/Presenter (а может передаваться и тот же DTO). --> ViewModel/Presenter --> View.
источник

PA

Pavel Aleksandrov in Android Architecture
Pavel Aleksandrov
То есть, получается такая цепочка: Данные Из View --> ViewModel/Presenter (если они нужны). Здесь они превращаются в промежуточный объект для UseCase. --> UseCase --> Repository. Здесь данные превращаются в объект для IO. --> IO.

Ответ: IO --> Repository. Здесь данные превращаются в бизнес-объект. --> UseCase. Здесь данные превращаются в объект для ViewModel/Presenter (а может передаваться и тот же DTO). --> ViewModel/Presenter --> View.
Я правильно понял?
источник

A

Alexey in Android Architecture
QMan
При использовании rx, Вы должны отписываться / подписываться в самом фрагменте, в методах onStart() и onStop() например, на Ваш subject
У меня во фрагмент уже лайвдата приходит, dispose делаю в onCleared() у viewmodelи
источник

НЭ

Некрутов Эдуард... in Android Architecture
Вопрос к знатокам по неймингу? Все называют данные dto, потому что они передаются между слоями?

Мое мнение, что dto это именно перемещаемые объекты и больше подходят для data слоя.
В domain лучше назвать классы данных Entity, и позволить им в редких случаях иметь вспомогательные методы.
В presentation слое использовать Model для отображения.
А для передачи между экранами использовать например Data.

А то часто встречал, что по всему проекту летают разные dto и непонятно это dto какого слоя.
А вы как делаете?
источник

PA

Pavel Aleksandrov in Android Architecture
Alexey
У меня во фрагмент уже лайвдата приходит, dispose делаю в onCleared() у viewmodelи
Но ведь выносить компоненты Андроида в другие слои не очень здорово?
источник

НЭ

Некрутов Эдуард... in Android Architecture
Pavel Aleksandrov
То есть, получается такая цепочка: Данные Из View --> ViewModel/Presenter (если они нужны). Здесь они превращаются в промежуточный объект для UseCase. --> UseCase --> Repository. Здесь данные превращаются в объект для IO. --> IO.

Ответ: IO --> Repository. Здесь данные превращаются в бизнес-объект. --> UseCase. Здесь данные превращаются в объект для ViewModel/Presenter (а может передаваться и тот же DTO). --> ViewModel/Presenter --> View.
В domain слое нету никаких мапперов. Дто маппится в репозитории. В presenter прилетает объект из доменного слоя и там отображается сразу или после небольшого форматирования(вставить в строку из ресурсов например)
источник

A

Alexey in Android Architecture
Pavel Aleksandrov
Но ведь выносить компоненты Андроида в другие слои не очень здорово?
Так вьюмодель и фрагмент в одном слое
источник
2020 May 29

PA

Pavel Aleksandrov in Android Architecture
Alexey
Так вьюмодель и фрагмент в одном слое
А, то есть ты где-то в use-case превращаешь данные в LiveData, которые потом уходят в ViewModel?
источник

НЭ

Некрутов Эдуард... in Android Architecture
Pavel Aleksandrov
А, то есть ты где-то в use-case превращаешь данные в LiveData, которые потом уходят в ViewModel?
Ты отдаешь данные из useCase во вьюмодель и там уже превращаешь в live data
источник

PA

Pavel Aleksandrov in Android Architecture
Понял. Спасибо большое всем
источник

НЭ

Некрутов Эдуард... in Android Architecture
Pavel Aleksandrov
Понял. Спасибо большое всем
А по неймингу ты как делаешь? Все dto?
источник

A

Alexey in Android Architecture
Некрутов Эдуард
Ты отдаешь данные из useCase во вьюмодель и там уже превращаешь в live data
Да именно так, во вьюмодели получаю данные асинхронно через rx и присваиваю их в лайвдату
источник

PA

Pavel Aleksandrov in Android Architecture
Некрутов Эдуард
А по неймингу ты как делаешь? Все dto?
В Domain – entities. в Data-слое обычно Response. Аббревиатуру DTO ни в каком слое не пишу, просто на словах привык так говорить
источник

НЭ

Некрутов Эдуард... in Android Architecture
Pavel Aleksandrov
В Domain – entities. в Data-слое обычно Response. Аббревиатуру DTO ни в каком слое не пишу, просто на словах привык так говорить
А. Ок. Просто в текущем легаси проекте dto это любой класс с данными)) И вот интересно, только ли у нас так или это общепринятая практика)
источник

PA

Pavel Aleksandrov in Android Architecture
А нормально ли "тащить" данные в в обёртке типо <Success, Failure> прям до ViewModel и там уже отобразить их во View? Или всё-таки нужно ещё до этого "развернуть" обёртку в entity бизнес-логики? Особенно интересует это, чтобы понять где обрабатывать результат suspend функции.
источник

АЕ

Алексей Ершов... in Android Architecture
Мне кажется эта обёртка нужна только для expected ошибок, чтобы их в бизнес-логике обработать.
источник

НЭ

Некрутов Эдуард... in Android Architecture
Pavel Aleksandrov
А нормально ли "тащить" данные в в обёртке типо <Success, Failure> прям до ViewModel и там уже отобразить их во View? Или всё-таки нужно ещё до этого "развернуть" обёртку в entity бизнес-логики? Особенно интересует это, чтобы понять где обрабатывать результат suspend функции.
У нас rx, с корутинами не работал, так что не знаю как там это конкретно реализовывается.
Ты в репозитории получаем данные или ексепшен. Исключения проверяем, можем ли их обернуть в ожидаемые исключения, и пробрасываем через onError. В интеракторе логика получает данные, работает с ними и если получается ошибка логики, то отдается <Success, Fail>. В презентере обрабатываются хорошие данные и ошибки логики. А ожидаемые исключения пробрасывается в ErrorHandler и там обрабатываются одинаково.
источник

АЕ

Алексей Ершов... in Android Architecture
источник

АЕ

Алексей Ершов... in Android Architecture
Мне понравился доклад про ошибки, рекомендую.
источник