Репозиторий чистой архитектуры
Создание приложения с использованием архитектуры, рекомендованной Google, кажется хорошим способом разделения и модульности приложения. При этом я часто натыкаюсь на тот факт, что при кэшировании данных, поступающих из API, может возникнуть необходимость в использовании различных моделей для удаленных и локальных источников данных. (Я нашел комментарий здесь от swankjesse, в котором говорится то же самое).
Различные модели выглядят красиво, но наличие сложных моделей с несколькими уровнями вложенности кажется головной болью (сопоставление локальных и удаленных моделей с общей сущностью data layer).
Другой аргумент заключается в том, что при запросе данных из сети API может ответить разбивкой на страницы сопоставления JSON и другими вещами внутри (которые необходимы ViewModel (только пример) для загрузки дополнительных данных).
Наличие Repository с локальными и удаленными источниками данных выглядит как бы испорченным (локальный отвечает списком объектов, удаленный отвечает классом, содержащим список объектов).
Все примеры приложений, которые я видел, демонстрируют использование простых POJO (что в производственном коде почти никогда не бывает реалистичным). Есть идеи по решению этой архитектурной головоломки?
Ответы 1
Я предполагаю, что у вас есть такие модули с соответствующей моделью данных:
- Модуль
domainсUserItem - Модуль
repositoryсодержит 2 источника данных: модульremote(Retrofit - сUserResponse) и модульlocal(Room - сUserEntity). Также внутри модуляUserMapperнаходитсяrepository.
Зачем нам нужны 3 разные модели данных для представления User? Потому что в 3-х таких модулях данные имеют разный формат, а также аннотации. Например, User будет иметь поле birthday:
- Модуль
remote:class UserResponse(@SerializedName("birthday_date") val birthdayDate: String) - Модуль
local:
@Entity(tableName = "users")
class UserEntity(
@ColumnInfo(name = "birthday") val birthday: Long
)
domain:class UserItem(val birthdayDate: Long)
С 3 различными моделями данных вы можете легко изменять данные в domain, не беспокоясь о любых критических изменениях в local или remote.