С какими работал MV паттернами кроме MVVM

Ответ

  • MVC (Model-View-Controller) – классический паттерн, где View отображает данные, Controller обрабатывает логику, Model хранит данные. В Android Activity/Fragment часто совмещает View и Controller, что приводит к раздуванию кода.

  • MVP (Model-View-Presenter) – более четкое разделение: View (Activity/Fragment) отвечает за UI, Presenter – за логику, Model – за данные. Пример:

class MainPresenter(private val view: MainView) {
    fun loadData() {
        val data = Model.getData()
        view.showData(data)
    }
}
  • MVI (Model-View-Intent) – односторонний поток данных. View отправляет Intent (действия), Model обрабатывает и возвращает State, View отображает его. Используется с Kotlin Flow/RxJava.

  • Clean Architecture – не строго MV*, но часто комбинируется с MVP/MVVM. Разделение на слои (Domain, Data, Presentation) для улучшения тестируемости и поддержки.

Ответ 18+ 🔞

Ну слушай, история с этими архитектурными паттернами в андроиде — это просто ёперный театр, ей-богу. Как будто на дворе 2002-й год и все только про MVC слышали.

Вот смотри. MVC (Model-View-Controller) — это типа классика, старая, как говно мамонта. View рисует, Controller рулит, Model данные хранит. А в андроиде что вышло? Да Activity или Fragment взяли и совместили в себе и View, и Controller! Получилась такая пиздопроебибна монструозная хрень, где в одном файле на 2000 строк и кнопки вешаешь, и в сеть ходишь, и в БД пишешь. Терпения ноль ебать, когда в таком коде что-то искать.

Потом умные люди придумали MVP (Model-View-Presenter). Тут уже чётче. View (это наш Activity) — дурак, только показывает кнопки и рисует данные. Вся логика — в Presenter'е. Model как была, так и осталась хранилищем. Смотри, как примерно:

class MainPresenter(private val view: MainView) {
    fun loadData() {
        val data = Model.getData() // Достал из модели
        view.showData(data) // Сказал вьюхе: рисуй!
    }
}

Стало лучше, да. Но появилась другая засада — эти View интерфейсы на 100500 методов, которые Presenter вызывает. И связка Presenter-View, которую надо аккуратно разрывать, чтобы утечек памяти не было. Подозрение ебать чувствую к этой ручной возне.

Дальше пошла мода на реактивщину и появился MVI (Model-View-Intent). Во, тут вообще ни хуя себе подход. Односторонний поток, как в воронку. View шлёт Intent (намерение, типа "пользователь нажал кнопку"). Модель (или какой-то обработчик) этот Intent переваривает и выдаёт новый State (состояние). View этот State просто тупо отображает. Всё, цикла нет. Красиво, строго, но мозг сначала сломать можно. Без Kotlin Flow или RxJava там делать нечего — сразу хуй с горы.

А потом ещё подвезли Clean Architecture. Это вообще не про MV* конкретно, а про слоёный пирог. Домен, данные, презентация — всё отдельно. Цель — чтобы можно было тесты писать и чтобы база данных или апишка могли поменяться без перелопачивания всей логики. Его часто с MVP или MVVM скрещивают. Мощная штука, но для маленького проекта — это как из пушки по воробьям, овердохуища boilerplate-кода.

Короче, выбор зависит. Хочешь просто и быстро — MVP. Ощущаешь себя архитектурным гуру и проект сложный — MVI или Clean. Главное — не скатываться в тот старый ад с MVC, где Activity — это бог, царь и воин, иначе потом поддерживать этот код будут те, кто тебя на хуй пошлёт.