Архитектура и модели в мобилната разработка: какво е, какви са видовете и как да се прилагат

Основни архитектурни модели

Архитектурният модел определя как се разпределят отговорностите между класовете на приложението. Изборът на модел влияе върху лекотата на добавяне на нови екрани и тестване на кода.

MVC (Model-View-Controller)

MVC е класически модел, при който Model управлява данни, View — визуализация, а Controller — логика. В iOS MVC е по подразбиране (UIViewController); в Android — Activity. Недостатъкът е, че Controller често става "масивен" (Massive View Controller). Според проучване сред iOS разработчици (Reddit, 2025), 62% посочват MVC като основна причина за нечетим код в стари проекти.

MVP (Model-View-Presenter)

MVP се различава по това, че Presenter управлява View чрез интерфейс, подобрявайки тестваемостта. MVP беше популярен в Android преди Jetpack, но изостава от MVVM по удобство.

MVVM (Model-View-ViewModel)

MVVM е препоръчваният модел от Google за Android и от Apple за iOS. ViewModel съхранява състояние, а View се абонира за промени чрез Data Binding или @Published. ViewModel не зависи от View и лесно се тества. В IT Sectr използваме MVVM като основен модел във всички проекти.

MVI и VIPER

MVI е реактивен модел, при който всяко действие следва цикъла Intent → Model → View. MVI гарантира предвидимо състояние. VIPER е iOS модел с пет слоя (View, Interactor, Presenter, Entity, Router), осигуряващ максимална изолация, но изискващ много шаблонен код.

Clean Architecture

Clean Architecture е концепция на Робърт Мартин, която разделя приложението на слоеве: външните слоеве (UI, БД, мрежа) зависят от вътрешните (бизнес логика, същности). В мобилната разработка Clean Architecture включва три слоя: data (репозитории), domain (Use Cases) и presentation (ViewModels, UI).

Repository Pattern е ключов компонент на Clean Architecture, който абстрахира източника на данни. Репозиторият решава дали да вземе данни от мрежата или от локално хранилище (Room, Core Data) и връща унифициран формат. Според Google (Architecture Guide, 2025), Repository Pattern се препоръчва за всяко приложение с мрежови заявки. Clean Architecture е оправдана в проекти с 3–5 екрана или повече — за прости приложения започнете с MVVM.

Създаващи модели

Singleton

Singleton е архитектурен модел, който гарантира единствен екземпляр на клас и предоставя глобална точка за достъп до него. Използва се за бази данни, мениджъри на настройки и кеш. В Kotlin се създава чрез object. Недостатъкът е, че усложнява тестването поради глобалното състояние.

Factory и Builder

Factory делегира създаването на обекти на фабричен метод — вместо new извиквате фабриката. Builder е модел за поетапно конструиране на сложни обекти с множество параметри (AlertDialog.Builder, NotificationCompat.Builder). Builder подобрява четимостта и позволява обектите да останат неизменни след сглобяване.

Структурни и поведенчески модели

Adapter, Facade, Delegate, Protocol

Adapter е архитектурен модел, който преобразува интерфейса на един клас в интерфейс, очакван от клиента. В Android това е RecyclerView.Adapter. Facade предоставя опростен интерфейс към сложна система — например фасада за API, скриваща детайлите за удостоверяване. Delegate е iOS модел, при който обект делегира задача (UITableViewDelegate). Protocol е еквивалентът на интерфейс в Swift.

Observer и Strategy

Observer е модел за абониране за промени: субектът уведомява абонатите за актуализации. В мобилната разработка Observer е основата на LiveData, StateFlow, RxJava и Combine. Strategy е модел на взаимозаменяеми алгоритми: включвате различна стратегия (сортиране, валидация) без множество if-else изрази.

Внедряване на зависимости и управление на състоянието

Dependency Injection е архитектурен модел, при който обект получава зависимостите си отвън, вместо да ги създава сам. Вместо new Database(), предавате базата данни чрез конструктора. DI опростява тестването — можете да използвате Mock вместо реална база данни — и улеснява смяната на реализации. Популярни DI рамки: Dagger и Hilt (Android), Swinject (iOS), Koin (Kotlin). Hilt — обвивка около Dagger, препоръчана от Google, намалява настройката на DI 3 пъти.

Service Locator е алтернатива на DI с централен регистър на зависимостите. По-лесен за внедряване, но скрива зависимостите на класа, затруднявайки тестването. Съвременните проекти предпочитат DI чрез Hilt или Koin.

Управление на състоянието във Flutter

Във Flutter управлението на състоянието е отделна екосистема. Redux — единично Store с промени чрез Actions → Reducer → State. BLoC на Google разделя събития и състояния чрез Stream. Provider — прост DI контейнер, препоръчан от Google за Flutter до 2023. Riverpod — подобрен Provider, решаващ проблеми с компилация и тестване. GetX — микро-рамка с маршрутизация, DI и управление на състоянието. За начинаещи Flutter разработчици препоръчваме Provider или Riverpod като най-добре документираните решения.

Принципи SOLID и DRY

Освен конкретните модели, съществуват общи принципи на архитектурно проектиране, приложими във всеки език и рамка.

SOLID — пет принципа на обектно-ориентираното проектиране: Single Responsibility (един клас — една задача), Open-Closed (отворен за разширение, затворен за промяна), Liskov Substitution (подкласовете заместват родителския клас), Interface Segregation (малки интерфейси), Dependency Inversion (зависимост от абстракции). В мобилната разработка SRP е най-полезният принцип: всеки клас прави само едно нещо. Според опита на IT Sectr, нарушаването на SRP е причина за 70% от проблемите с тестването в търговски проекти.

// Пример: нарушение SRP
class UserManager {
    fun saveUser(user: User) { /* сохранение */ }
    fun validateEmail(email: String): Boolean { /* валидация */ }
    fun sendEmail(user: User) { /* отправка */ }
    fun formatUser(user: User): String { /* форматирование */ }
}

// Исправление: разделяем на отдельные классы
class UserRepository { fun save(user: User) {} }
class EmailValidator { fun isValid(email: String): Boolean {} }
class EmailService { fun send(user: User) {} }
class UserFormatter { fun format(user: User): String {} }

Примерът на Kotlin показва как превръщаме един клас UserManager с четири отговорности в четири класа с по една отговорност. Такъв код е по-лесен за тестване, промяна и повторна употреба.

DRY (Don't Repeat Yourself) — избягвайте дублиране на код. Изваждайте повтарящата се логика в споделени методи или класове. KISS (Keep It Simple, Stupid) — простотата е по-важна от елегантността. YAGNI (You Aren't Gonna Need It) — не пишете код за нещо, което може да не е необходимо. Тези принципи помагат за писане на чист, поддържаем код без излишество.

Платформени модели за Android

ViewModel (Android) е компонент на архитектурата Jetpack за съхраняване на UI състояние, устойчив на завъртане на екрана. ViewModel не съдържа препратки към Activity и се изчиства автоматично. LiveData — наблюдаем контейнер за данни с осъзнаване на жизнения цикъл. StateFlow — модерен заместител на LiveData, базиран на Kotlin Flow. SharedFlow — Hot Flow за еднократни събития (навигация, тост съобщения).

Data Binding и Two-Way Binding — механизми за свързване на UI и данни в Android. Data Binding декларира връзката в XML; Two-Way Binding автоматично актуализира полето в ViewModel. Unidirectional Data Flow — принцип, при който данните текат в една посока: State → UI → Event → State. В IT Sectr използваме Unidirectional Data Flow във всички нови проекти — това намалява броя на грешките, причинени от неочаквани промени в състоянието.