Какие сущности используются в Data и Presentation слоях

Архитектура Data и Presentation слоев в Android

В современной Android разработке, особенно при использовании таких подходов как Clean Architecture или MVVM, четкое разделение на слои является ключевым принципом. Data Layer отвечает за управление данными, их получение, преобразование и сохранение, а Presentation Layer (или UI Layer) — за отображение этих данных пользователю и обработку взаимодействий. Ниже подробно рассмотрены основные сущности каждого слоя.

Data Layer (Слой данных)

Этот слои является фундаментом приложения. Его основная ответственность — абстрагирование источников данных (локальных и удаленных) и предоставление единого интерфейса для остальных частей приложения.

Ключевые сущности Data Layer:

1. Repository (Репозиторий)

    *   **Цель**: Центральный элемент слоя. Агрегирует данные из различных источников (`DataSource`), выполняет бизнес-логику их объединения (например, кэширование) и предоставляет чистый, готовый к использованию поток данных для Presentation слоя.
    *   **Пример**: `UserRepository`, который может получать данные из сети и локальной базы данных.

```kotlin
class UserRepository(
    private val remoteDataSource: UserRemoteDataSource,
    private val localDataSource: UserLocalDataSource
) {
    fun getUser(id: String): Flow<User> {
        return flow {
            // Попытка получить из локального источника
            val localUser = localDataSource.getUser(id)
            if (localUser != null) emit(localUser)
            
            // Запрос к сети и сохранение результата
            val remoteUser = remoteDataSource.getUser(id)
            localDataSource.saveUser(remoteUser)
            emit(remoteUser)
        }
    }
}
```

2. DataSource (Источник данных)

    *   **Цель**: Конкретная реализация получения данных из определенного источника. Разделяется на **RemoteDataSource** (для API, сетевых запросов) и **LocalDataSource** (для локального хранилища: база данных, SharedPreferences, файлы).
    *   **Пример**: `UserRemoteDataSource`, использующий Retrofit для HTTP-запросов, и `UserLocalDataSource`, использующий Room для работы с SQLite.

1. Model / Entity (Модель / Сущность)

    *   **Цель**: Объекты данных, которые циркулируют внутри Data Layer. Часто это точные представления моделей из API (`DTO` — Data Transfer Object) или схемы таблиц базы данных (`Entity`). Они могут отличаться от моделей, используемых в UI.

```kotlin
// Entity для Room (LocalDataSource)
@Entity(tableName = "users")
data class UserEntity(
    @PrimaryKey val id: String,
    val name: String,
    val email: String
)

// DTO для Retrofit (RemoteDataSource)
data class UserDto(
    val id: String,
    val login: String,
    @SerializedName("email_address") val emailAddress: String
)
```

4. Data Mapper (Преобразователь данных)

    *   **Цель**: Сущность (часто в виде простой функции или класса), которая преобразует модели Data Layer (`DTO`, `Entity`) в модели Domain или UI слоя, и наоборот. Это обеспечивает независимость слоев.

Presentation Layer (Слой представления / UI)

Этот слои отвечает за все, что связано с пользовательским интерфейсом. Он получает данные из Data Layer (обычно через Domain Layer или напрямую) и решает, как их отобразить и как реагировать на действия пользователя.

Ключевые сущности Presentation Layer:

1. ViewModel

    *   **Цель**: Главная сущность, связывающая UI и данные. Она **не является частью Android Framework UI** (жизненный цикл привязывается к `LifecycleOwner`). `ViewModel` хранит и управляет **состоянием UI**, связанным с данными, предоставляет методы для обработки пользовательских событий (`user events`), и взаимодействует с `Repository` для получения данных.
    *   **Ключевые концепции**: **State** (состояние) и **Event** (событие). Состояние описывает, что должно быть показано на экране (загружается, успешно загружено с данными, ошибка). События — это интерактивные действия, которые должен обработать ViewModel.

```kotlin
class UserViewModel(private val repository: UserRepository) : ViewModel() {
    // State как StateFlow
    private val _userState = MutableStateFlow<UserState>(UserState.Loading)
    val userState: StateFlow<UserState> = _userState.asStateFlow()

    fun loadUser(id: String) {
        viewModelScope.launch {
            repository.getUser(id).collect { user ->
                _userState.value = UserState.Success(user)
            }
        }
    }

    // Обработка события от UI
    fun onRefreshClicked() {
        loadUser("currentUserId")
    }
}

// Модель состояния UI
sealed class UserState {
    object Loading : UserState()
    data class Success(val user: User) : UserState()
    data class Error(val message: String) : UserState()
}
```

2. UI Model (UI State Model)

    *   **Цель**: Модели данных, специально подготовленные для отображения. Они могут объединять данные из нескольких источников, добавлять форматирование (например, даты) или флаги видимости. Часто представляются как sealed class для описания различных состояний экрана (Loading, Success, Error).

1. UI Component (Activity, Fragment, Composable)

    *   **Цель**: Конкретные компоненты Android UI (`Activity`, `Fragment`) или декларативные функции **Jetpack Compose**. Они:
        *   **Отображают состояние**: Наблюдают за `StateFlow` или `LiveData` из `ViewModel` и обновляют UI.
        *   **Передают события**: Передают пользовательские действия (нажатия кнопок, ввод текста) в `ViewModel` через его публичные методы.

```kotlin
@Composable
fun UserScreen(viewModel: UserViewModel = viewModel()) {
    val userState by viewModel.userState.collectAsStateWithLifecycle()

    Column {
        when (userState) {
            is UserState.Loading -> { Text("Загрузка...") }
            is UserState.Success -> {
                Text("Имя: ${userState.user.name}")
                Button(onClick = { viewModel.onRefreshClicked() }) {
                    Text("Обновить")
                }
            }
            is UserState.Error -> { Text("Ошибка!") }
        }
    }
}
```

Связь между слоями

Ключевой момент: Presentation Layer никогда не напрямую обращается к DataSource или сетевому клиенту. Все запросы данных происходят через Repository, который предоставляется ViewModel. Это обеспечивает:

• Тестируемость: ViewModel и Repository можно тестировать независимо от Android компонентов.
• Изменяемость: Источник данных (например, переход с REST на GraphQL) можно изменить, затрагивая только Data Layer.
• Предотвращение утечек памяти: ViewModel правильно управляет корутинами и избегает ссылок на UI объекты.

Таким образом, Repository и ViewModel выступают основными "мостами" между Data и Presentation слоями, обеспечивая чистую архитектуру, поддерживаемость и надежность приложения.