Какие плюсы и минусы MVVM?

MVVM: Плюсы и Минусы в Android Разработке

MVVM (Model-View-ViewModel) — это архитектурный паттерн, который позволяет разделить логику приложения на независимые слои. В Android это стандартный подход, рекомендуемый Google. Давайте разберём его достоинства и недостатки.

Плюсы MVVM

1. Разделение ответственности

Каждый слой отвечает за своё:

• Model: данные и бизнес-логика
• View: только отображение
• ViewModel: подготовка данных для View

// ViewModel отделён от View логики
class UserViewModel(private val userRepository: UserRepository) : ViewModel() {
    private val _users = MutableLiveData<List<User>>()
    val users: LiveData<List<User>> = _users
    
    fun loadUsers() {
        viewModelScope.launch {
            _users.value = userRepository.getUsers()
        }
    }
}

// Fragment только отображает
class UserFragment : Fragment() {
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        viewModel.users.observe(viewLifecycleOwner) { users ->
            adapter.submitList(users)
        }
    }
}

2. Переживание конфигурационных изменений

ViewModel сохраняется при повороте экрана, смене языка и т.д.:

// Данные не теряются при rotation!
val viewModel: UserViewModel by viewModels()

// До MVVM пришлось бы вручную сохранять состояние:
// override fun onSaveInstanceState(outState: Bundle) { ... }

3. Тестируемость

ViewModel можно тестировать без Android контекста:

@Test
fun testLoadUsers() {
    val repository = FakeUserRepository()  // Mock
    val viewModel = UserViewModel(repository)
    
    viewModel.loadUsers()
    
    assertEquals(expectedUsers, viewModel.users.value)
}

4. Переиспользование кода

Одна ViewModel может использоваться несколькими Fragments:

// SharedViewModel для обмена данными между фрагментами
class SharedViewModel : ViewModel() {
    val selectedUser = MutableLiveData<User>()
}

// Fragment 1 устанавливает
sharedViewModel.selectedUser.value = user

// Fragment 2 слушает
sharedViewModel.selectedUser.observe(viewLifecycleOwner) { user ->
    updateUI(user)
}

5. Масштабируемость

Проект растёт без архитектурного хаоса благодаря чёткому разделению.

Минусы MVVM

1. Кривая обучения

Нужно понять несколько концепций:

• LiveData и StateFlow
• ViewModelScope
• Data Binding
• Lifecycle awareness

// Для новичка это может быть сложно
fragment.viewLifecycleOwner.lifecycleScope.launchWhenStarted {
    viewModel.uiState.collect { state ->
        when (state) {
            is Loading -> showLoading()
            is Success -> showData(state.data)
            is Error -> showError(state.exception)
        }
    }
}

2. Много boilerplate кода

Даже простой экран требует много кода:

// Model
data class User(val id: Int, val name: String)

// Repository
class UserRepository {
    suspend fun getUsers(): List<User> = /* fetch */
}

// ViewModel
class UserViewModel(repository: UserRepository) : ViewModel() {
    private val _users = MutableLiveData<List<User>>()
    val users: LiveData<List<User>> = _users
    
    fun loadUsers() { /* ... */ }
}

// View (Fragment)
class UserFragment : Fragment(R.layout.fragment_users) {
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        viewModel.users.observe(viewLifecycleOwner) { /* ... */ }
    }
}

3. Сложность с асинхронностью

Нужно правильно управлять корутинами и Lifecycle:

// ❌ Утечка памяти — viewModelScope забывают
launchIO {
    // Данные могут прийти после уничтожения Fragment
}

// ✅ Правильно — используй viewModelScope
viewModelScope.launch {
    _users.value = repository.getUsers()
}

4. Проблемы с UI State

LiveData может не передать состояние новому подписчику:

// ❌ Если подписаться после события, его не видишь
viewModel.event.observe(viewLifecycleOwner) { event ->
    // Может быть null, если событие уже произошло
}

// ✅ Используй StateFlow вместо LiveData
private val _event = MutableStateFlow<Event?>(null)
val event: StateFlow<Event?> = _event.asStateFlow()

5. Сложная трассировка ошибок

Применение паттерна усложняет отладку:

// Ошибка может быть на любом уровне
ViewModel -> Repository -> Network -> Database

// Нужно логировать на каждом уровне
// иначе ошибка может потеряться

Альтернативные паттерны

MVI (Model-View-Intent)

Похож на MVVM, но с явным потоком данных:

// Интенты от пользователя
seal class UserIntent {
    object LoadUsers : UserIntent()
    data class SelectUser(val id: Int) : UserIntent()
}

// ViewState
data class UserViewState(
    val users: List<User>,
    val loading: Boolean,
    val error: Exception?
)

Clean Architecture + DDD

Полная развязка слоёв:

• Presentation (UI, ViewModel)
• Application (UseCase, Services)
• Domain (Entities, Repositories интерфейсы)
• Infrastructure (Database, Network)

Когда использовать MVVM

✅ Используй MVVM когда:

• Стандартный Android проект
• Нужна переживаемость конфигурационных изменений
• Важна тестируемость
• Среднего размера приложение

❌ Избегай MVVM когда:

• Очень простое приложение (single screen)
• Нужна максимальная производительность
• Большой, сложный проект (используй Clean Architecture)

Лучшие практики

// 1. Используй StateFlow вместо LiveData
private val _uiState = MutableStateFlow<UiState>(UiState.Loading)
val uiState: StateFlow<UiState> = _uiState.asStateFlow()

// 2. Всегда используй viewModelScope
viewModelScope.launch {
    // Безопасные корутины
}

// 3. Разделяй на составные ViewModels
class UserListViewModel
class UserDetailViewModel
class UserEditViewModel

// 4. Используй Repository паттерн
private val repository = UserRepository(apiService, database)

// 5. Тестируй отдельно View и ViewModel

Вывод: MVVM — это мощный и проверенный паттерн для Android разработки, но не панацея. Выбирай архитектуру в зависимости от размера и сложности проекта.