Репозиторий чистой архитектуры

Question

Создание приложения с использованием архитектуры, рекомендованной Google, кажется хорошим способом разделения и модульности приложения. При этом я часто сталкиваюсь с тем фактом, что при кэшировании данных, поступающих из API, может возникнуть необходимость в использовании различных моделей для удаленных и локальных источников данных. (Я нашел комментарий здесь от swankjesse, в котором говорится то же самое).

Различные модели выглядят хорошо, но наличие сложных моделей с несколькими уровнями вложенности, похоже, является проблемой в заднице (отображение локальных и удаленных моделей в общую сущность data layer).

Другим аргументом может быть то, что при запросе данных из сети API может ответить пагинацией отображения JSON и другим содержимым внутри (что требуется ViewModel (просто пример) для загрузки большего количества данных). Наличие Repository с локальными и удаленными источниками данных выглядит как-то разрушено (локальный отвечает списком объектов, удаленный - классом, содержащим список объектов).

Все примеры приложений, которые я видел, демонстрируют использование простых POJO (что в производственном коде почти никогда не реалистично). Есть идеи по решению этой архитектурной головоломки?

Answer 1

Я предполагаю, что у вас есть такие модули с соответствующей моделью данных:

• Модуль domain с UserItem
• Модуль repository содержит 2 источника данных: модуль remote (дооснащение - с UserResponse) и модуль local (комната - с UserEntity). Внутри repository есть также модуль UserMapper.

Зачем нам нужны 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