MVC: суть паттерна Model-View-Controller и его реализация

Что такое MVC: суть паттерна Model-View-Controller

MVC (Model-View-Controller) — архитектурный паттерн, предложенный Trygve Reenskaug в 1979 году для языка Smalltalk-80. Паттерн разделяет приложение на три слоя: Model содержит данные и бизнес-логику, View отвечает за отображение, Controller обрабатывает пользовательский ввод и обновляет Model и View. Разделение ответственности позволяет изменять каждый слой независимо — например, заменить View с UIKit на SwiftUI без изменения бизнес-логики в Model.

Взаимодействие компонентов в MVC следует циклу: пользователь взаимодействует с View → Controller получает событие → Controller обновляет Model → Model уведомляет Controller об изменениях → Controller обновляет View. В классической реализации Model использует Observer-паттерн: при изменении данных Model рассылает уведомления, Controller подписывается и обновляет View. В Apple-реализации Key-Value Observing (KVO) или NotificationCenter выполняют эту роль.

MVC в современной мобильной разработке используется реже, чем 10 лет назад, но остаётся обязательным для понимания. Apple рекомендует MVC для простых экранов в UIKit-приложениях. Google не рекомендует чистый MVC для Android — официальная документация предлагает MVVM с Jetpack. Однако знание MVC необходимо для работы с унаследованными проектами и для понимания эволюции архитектурных паттернов.

MVC в iOS: UIViewController и storyboard

Apple MVC — кастомная реализация паттерна, встроенная в UIKit. UIViewController выполняет роль Controller: управляет жизненным циклом экрана (viewDidLoad, viewWillAppear, viewDidDisappear), обрабатывает touches и действия пользователя, обновляет View через IBOutlets. View создаётся в Interface Builder (storyboard или XIB) или программно. Model — это любые объекты данных: сетевые сервисы, CoreData стеки, структуры Swift.

final class UserViewController: UIViewController {
    // View (через storyboard outlet)
    @IBOutlet private var nameLabel: UILabel!
    @IBOutlet private var emailLabel: UILabel!

    // Model
    private let userService = UserService()

    override func viewDidLoad() {
        super.viewDidLoad()
        loadUser()
    }

    private func loadUser() {
        userService.fetchUser { [weak self] user in
            // Controller обновляет View
            self?.nameLabel.text = user.name
            self?.emailLabel.text = user.email
        }
    }
}

Проблема Apple MVC — View и Controller тесно связаны. UIViewController одновременно управляет и View, и логикой. Storyboard хранит View в XML, но контроллер имеет прямые ссылки на UI-элементы через IBOutlets. Это нарушает принцип единственной ответственности: контроллер отвечает за жизненный цикл, делегаты, datasource, target-action и анимации. В результате стандартный экран iOS-приложения содержит 200–500 строк в контроллере.

ViewController lifecycle — Apple предоставляет 6 методов жизненного цикла: loadView (создание View вручную), viewDidLoad (после загрузки View в память), viewWillAppear (перед появлением на экране), viewDidAppear (после анимации), viewWillDisappear (перед уходом с экрана), viewDidDisappear (после ухода). Каждый метод — место для размещения логики в MVC. Использование этих методов для бизнес-логики ускоряет рост контроллера.

MVC в Android: Activity, Fragment и XML layout

Android MVC — Activity и Fragment выполняют роль Controller, XML-файлы layout — View, любой POJO-класс с данными — Model. Activity управляет жизненным циклом экрана: onCreate, onStart, onResume, onPause, onStop, onDestroy. Fragment — подэкран внутри Activity с собственным жизненным циклом. View (XML) отделена от Controller и загружается через setContentView или LayoutInflater. Model — репозитории, базы данных, сетевые вызовы.

class UserActivity : AppCompatActivity() {
    // View через XML layout
    private lateinit var binding: ActivityUserBinding

    // Model
    private val userRepository = UserRepository()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityUserBinding.inflate(layoutInflater)
        setContentView(binding.root)
        loadUser()
    }

    private fun loadUser() {
        userRepository.getUser { user ->
            runOnUiThread {
                binding.nameText.text = user.name
                binding.emailText.text = user.email
            }
        }
    }
}

Android ViewBinding и DataBinding — современные инструменты, уменьшающие связность Controller и View. ViewBinding генерирует класс с прямыми ссылками на View из XML, устраняя findViewById. DataBinding добавляет возможность связывать данные с UI в XML-разметке через @{user.name}. DataBinding — шаг в сторону MVVM, так как позволяет передавать данные из Model в View без кода в Activity. Google рекомендует DataBinding для всех новых проектов.

Жизненный цикл Android сложнее iOS: Activity может быть уничтожена и пересоздана при повороте экрана, нехватке памяти или смене конфигурации. В чистом MVC контроллер (Activity) содержит логику, которая теряется при уничтожении. Это требует сохранения состояния через onSaveInstanceState или ViewModel из Jetpack, что выходит за рамки чистого MVC и приближает архитектуру к MVVM.

Massive View Controller и ограничения MVC

Massive View Controller — термин, описывающий главную проблему MVC в мобильной разработке. Контроллер в iOS и Android берёт на себя слишком много обязанностей: обработка ввода, валидация данных, сетевое взаимодействие, навигация, кэширование, анимации, управление жизненным циклом. В результате контроллер разрастается до 500–2000 строк кода, становится трудным для чтения, тестирования и поддержки.

Причины Massive View Controller — архитектура UIKit и Android Framework стимулирует размещение логики в контроллере. Сетевые вызовы, обработка JSON, навигация — всё это естественно писать в Activity или UIViewController, потому что они имеют доступ к жизненному циклу и UI. Разработчик должен сознательно выносить логику в отдельные классы (Service, Manager, Interactor), что требует дисциплины и понимания архитектурных принципов.

Тестирование MVC — Model тестируется изолированно unit-тестами. Controller тестировать сложно из-за зависимости от UIKit/UIFoundation. XCTest не позволяет создавать UIViewController без view window. Для Android ActivityTestRule и Robolectric частично решают проблему, но тесты медленные. View обычно не тестируется unit-тестами — для UI применяются скриншотные и UI-тесты (XCUITest, Espresso).

Когда MVC оправдан — простые экраны из одного-двух элементов (экран логина, профиля, настроек). Прототипы и MVP для проверки гипотез — MVC быстрее писать без дополнительных слоёв. Проекты с малой кодовой базой до 10–15 экранов. В сложных проектах MVC ведёт к накоплению технического долга и требует рефакторинга каждые 6–12 месяцев.

Сравнение MVC с MVVM, MVP и Clean Architecture

MVC vs MVVM — главное отличие: в MVVM контроллер заменён ViewModel, который не имеет ссылки на View. Данные передаются через Observable (SwiftUI), LiveData/StateFlow (Android) или Combine/RxSwift. ViewModel тестируется unit-тестами без UI-зависимостей. Apple рекомендует MVVM со SwiftUI с 2019 года, Google — MVVM с LiveData/Flow как официальную архитектуру Android. MVVM требует больше кода для связывания, но существенно улучшает тестируемость.

MVC vs MVP — в MVP (Model-View-Presenter) Presenter — это тестируемый слой, который получает View через интерфейс. В отличие от MVC, где Controller напрямую управляет View через UIKit, Presenter не зависит от фреймворка — он работает через абстракцию ViewInterface. MVP популярен в Android-разработке до появления Jetpack и используется в старых проектах. Presenter живёт дольше Activity и сохраняет состояние при повороте экрана.

MVC vs Clean Architecture — Clean Architecture добавляет слои Use Cases (Interactors), Entities, Gateways и Repository. MVC остаётся в Presentation слое, но бизнес-логика выносится в Domain слой с Use Cases. Clean Architecture решает проблему Massive View Controller радикально — Controller содержит только вызовы Use Cases и обновление View. Недостаток — значительное увеличение количества классов и файлов, что оправдано для проектов от 50+ экранов.

// MVC в iOS: Controller содержит всё
class OrderViewController: UIViewController {
    func placeOrder() {
        // Валидация + сеть + UI обновление
        guard Validation.isValid(total) else { return }
        NetworkService.shared.submit(order) { [weak self] result in
            self?.handleResult(result)
        }
    }
}

// MVVM: логика в ViewModel
class OrderViewModel: ObservableObject {
    @Published var state: OrderState = .idle
    func placeOrder() { /* бизнес-логика */ }
}

Выбор архитектуры зависит от размера команды, проекта и требуемой тестируемости. Для команды из 1–2 разработчиков и проекта до 20 экранов подойдёт MVVM. Для большой команды от 5 разработчиков и проекта от 50 экранов — Clean Architecture с модульной структурой. MVC остаётся актуальным для понимания эволюции архитектур, для поддержки легаси-проектов и для простых экранов в UIKit без сложной бизнес-логики.