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), обработва докосвания и действия на потребителя, актуализира 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 — Apple предоставя 6 метода на жизнения цикъл: loadView (ръчно създаване на View), viewDidLoad (след зареждане на View в паметта), viewWillAppear (преди появяване на екрана), viewDidAppear (след анимация), viewWillDisappear (преди напускане на екрана), viewDidDisappear (след напускане). Всеки метод — място за поставяне на логика в MVC. Използването на тези методи за бизнес логика ускорява растежа на контролера.

MVC в Android: Activity, Fragment и XML оформление

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

class UserActivity : AppCompatActivity() {
    // View чрез XML оформление
    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 се тества изолирано с единични тестове. Controller е труден за тестване поради зависимост от UIKit/UIFoundation. XCTest не позволява създаване на UIViewController без прозорец за изглед. За Android ActivityTestRule и Robolectric частично решават проблема, но тестовете са бавни. View обикновено не се тества с единични тестове — за 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 се тества с единични тестове без 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 без сложна бизнес логика.