🔍 Шаблон архитектуры MVC (Model View Controller)

Шаблон MVC предполагает разделение кода на 3 компонента. При создании класса/файла приложения разработчик должен отнести его к одному из следующих трёх уровней:

🔹 Модель:

Этот компонент хранит данные приложения. Он ничего не знает об интерфейсе. Модель отвечает за обработку логики предметной области (реальных бизнес-правил) и взаимодействие с базой данных и сетевыми уровнями.

🔹 Представление:

Это слой пользовательского интерфейса (UI), в котором содержатся компоненты, видимые на экране. Кроме того, он обеспечивает визуализацию данных, хранящихся в модели, и позволяет пользователю взаимодействовать с ними.

🔹 Контроллер:

Этот компонент устанавливает связь между Представлением и Моделью. Он содержит основную логику приложения, получает информацию о действиях пользователя и обновляет Модель в соответствии с потребностями.

Несмотря на применение схемы MVC для модульного проектирования приложения, уровни кода зависят друг от друга. В этом шаблоне Представление и Контроллер зависят от Модели. Для применения шаблона MVC в проекте можно использовать несколько подходов:

➡️ Подход 1: Действия и фрагменты могут выполнять роль контроллера и отвечать за обновление представления.

➡️ Подход 2: Используйте активность или фрагменты в качестве представлений и контроллера, а модель будет отдельным классом, который не наследуется от какого-либо класса Android.

В MVC данные обновляет контроллер, а представление их только отображает. Модель отделена и тестируется независимо от UI. Если представление соблюдает принцип единой ответственности — лишь передаёт действия контроллеру и показывает данные без бизнес-логики — то его достаточно проверять UI-тестами.

🐸 Библиотека мобильного разработчика

#буст #SeniorView #Android

👾 Шаблон архитектуры MVP

MVP (Model - View - Presenter) появился как альтернатива традиционному архитектурному паттерну MVC (Model - View - Controller). Используя MVC в качестве архитектуры приложения, разработчики сталкиваются со следующими трудностями:

🔘 Большая часть основной бизнес-логики находится в Controller. В течение жизненного цикла приложения этот файл становится всё больше и его становится сложно поддерживать.

🔘 Из-за тесной связки пользовательского интерфейса и механизмов доступа к данным, и Controller, и View оказываются в одной Activity или Fragment. Это создаёт проблемы при внесении изменений в функциональность приложения.

🔘 Становится трудно проводить модульное тестирование разных слоёв, так как большинство тестируемых частей зависят от компонентов Android SDK.

Паттерн MVP решает эти проблемы MVC и предоставляет простой способ структурировать код проекта. Причина, по которой MVP широко применяется, заключается в том, что он обеспечивает модульность, тестируемость и более чистую и удобную в сопровождении кодовую базу. Он состоит из следующих трёх компонентов:

🔹 Model: слой для хранения данных. Отвечает за обработку предметной логики (реальных бизнес-правил) и взаимодействие с базой данных и сетевым уровнем.

🔹 View: слой пользовательского интерфейса (UI). Он отвечает за визуализацию данных и отслеживает действия пользователя, чтобы уведомлять Presenter.

🔹 Presenter: получает данные из модели и применяет UI-логику, чтобы решить, что отображать. Он управляет состоянием View и выполняет действия в соответствии с уведомлениями о действиях пользователя.

🐸 Библиотека мобильного разработчика

#буст #SeniorView #Android

🧩 Почему Feature-модули не решают проблему масштабирования

Многие команды переходят к модульной архитектуре, надеясь, что разбив проект на feature-модули, они автоматически получат масштабируемость. На практике — чаще наоборот.

⚙️ В чём ошибка

Feature-модули решают структурную, а не архитектурную проблему.
Да, они:

• уменьшают время сборки,
• изолируют зависимости,
• упрощают навигацию по проекту.

Но если в каждом модуле копируется один и тот же UI-state, бизнес-логика и сетевой слой — ты не масштабируешь архитектуру, ты масштабируешь хаос.

🧠 Что действительно масштабируется

Масштабируется только архитектурная консистентность:

• единые контракты между слоями,
• повторно используемые базовые интерфейсы (например, для state-management или DI),
• стандартизированный подход к навигации и фичам.

Feature-модуль должен быть потребителем архитектурных решений, а не их источником.

✅ Практическая мысль

Прежде чем делить монолит на 20 модулей, ответь себе:

Есть ли у нас устойчивая архитектурная основа, которую эти модули смогут разделять?

Без этого модульность превращается в распыление ответственности, а не в масштабирование.

А как у вас реализована модульность в проекте? 💬

🐸 Библиотека мобильного разработчика

#АрхитектурныйКод #SeniorView

🎮 «Чистая» структура View-компонентов в SwiftUI

В проектах на SwiftUI тело View может быстро разрастись: десятки вложенных VStack/HStack, логика отображения, стили — всё в одном месте.

Вот три практики, которые помогут сделать код более понятным, гибким и удобным в сопровождении.

1️⃣ Извлечение отдельных View

Если часть интерфейса имеет собственное назначение — вынеси её в отдельный struct-View:

struct ArticleRow: View {
    let article: Article
    var body: some View {
        HStack { … }
    }
}

Затем:

ForEach(articles, id: \.url) { article in
    ArticleRow(article: article)
}

Это делает главный View более “обзорным” и облегчает повторное использование.


2️⃣ Использование ViewModifiers для стилей

Когда видишь дублирования стилей, вынеси их:

struct CardStyle: ViewModifier {
    func body(content: Content) -> some View {
        content
            .padding()
            .background(Color(.secondarySystemBackground))
            .cornerRadius(8)
    }
}
extension View {
    func cardStyle() -> some View {
        modifier(CardStyle())
    }
}

Теперь:

ArticleRow(article: article)
    .cardStyle()

Так ты централизуешь “язык дизайна” и можешь менять стиль в одном месте.

3️⃣ Создание универсальных расширений для просмотра

Если повторяются шаблоны (например, “заголовок секции”), можно сделать расширение:

extension View {
    func sectionHeader(_ title: String) -> some View {
        VStack(alignment: .leading, spacing: 4) {
            Text(title)
                .font(.title3)
                .bold()
            self
        }
    }
}

Пример:

VStack {
    ForEach(articles, id: \.url) { article in
        ArticleRow(article: article)
    }
}
.sectionHeader("Articles")

Такие расширения уменьшают вложенность и делают код декларативнее.

📌 Практическое руководство по созданию хорошей архитектуры SwiftUI

Если вы не уверены, стоит ли что-то извлекать, спросите:

Есть ли у этого элемента пользовательского интерфейса чёткое назначение и возможность повторного использования?

🔘 Если да → создайте новый View или ViewModifier.

🔘 Если нет → оставьте его локальным или используйте вычисляемое свойство.

Цель состоит не в том, чтобы сократить количество строк кода, а в том, чтобы повысить ясность и возможность повторного использования для улучшения архитектуры SwiftUI.

🐸 Библиотека мобильного разработчика

#АрхитектурныйКод #SeniorView #Swift

🔍 Архитектура Clean Swift

В Clean Swift приложение состоит из сцен, т.е. каждый экран приложения — это одна сцена. Основное взаимодействие в сцене идет через последовательный цикл между компонентами ViewController -> Interactor -> Presenter. Это называется VIP цикл.

Мостом между компонентами выступает файл Models, который хранит в себе передаваемые данные. Так же есть Router, отвечающий за переход и передачу данных между сценами, и Worker, который берет часть логики Interactor’a на себя.

🔹 View

Storyboard’ы, XIB’ы или UI элементы, написанные через код.

🔹 ViewController

Отвечает только за конфигурацию и взаимодействие с View. В контроллере не должно находиться никакой бизнес логики, взаимодействия с сетью, вычислений и так далее.
Его задача обрабатывать события с View, отображать или отправлять данные (без обработки и проверок) в Interactor.

🔹 Interactor

Содержит в себе бизнес логику сцены.

Он работает с сетью, базой данных и модулями устройства.

Interactor получает запрос из ViewController’a (с данными или пустой), обрабатывает его и, если это требуется, передает новые данные в Presenter.

🔹 Presenter

Занимается подготовкой данных для отображения.

Как пример, добавить маску на номер телефона или сделать первую букву в названии заглавной.
Обрабатывает данные, получение из Interactor’a, после чего отправляет их обратно во ViewController.

🔹 Models

Набор структур для передачи данных между компонентами VIP цикла. Каждый круг цикла имеет в себе 3 вида структур:

🔘 Request — Структура с данными (текст из TextField и т.д.) для передачи из ViewController'a в Interactor
🔘 Response — Структура с данными (загруженными из сети и т.д.) для передачи из Interactor в Presenter
🔘 ViewModel — Структура с обработанными данными (форматирование текста и т.д.) в Presenter’e для передачи обратно во ViewController

🔹 Worker

Разгружает Interactor, забирая на себя часть бизнес логики приложения, если Interactor стремительно разрастается.

Так же можно создавать общие для всех сцен Worker’ы, если их функционал используется в нескольких сценах.

Как пример, в Worker можно выносить логику работы с сетью или базой данных.

🔹 Router

В Router выносится вся логика, отвечающая за переходы и передачу данных между сценами.

____________________

Для прояснения картины работы VIP цикла приведу стандартный пример — авторизация.

1. Пользователь ввел свой логин и пароль, нажал на кнопку авторизации

2. У ViewController срабатывает IBAction, после чего создается структура с введенными, в TextField’ы, данными пользователя (Models -> Request)

3. Созданная структура передается в метод fetchUser в Interactor’e

4. Interactor отправляет запрос в сеть и получает ответ об успешности авторизации

5. На основе полученных данных, создает структуру с результатом (Models -> Response) и передается в метод presentUser в Presenter’e

6. Presenter форматирует данные по необходимости и возвращает их (Models -> ViewModel) в метод displayUser в ViewController’e

7. ViewController отображает полученные данные пользователю. В случае с авторизацией, может выводиться ошибка или срабатывать переход на другую сцену с помощью Router

Таким образом, мы получаем единую и последовательную структуру, с распределением обязанностей на компоненты.

🐸 Библиотека мобильного разработчика

#АрхитектурныйКод #SeniorView #Swift