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

Question

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

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

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

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

Answer 1

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

• модуль domain с участием UserItem
• модуль repository содержит 2 источника данных: модуль remote (Дооснащение - с UserResponse) и модуль local (Комната - с 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