В какой архитектурной паттерне UIViewController обычно содержит много логики?

А, слушай, смотри, вот этот ваш MVC, блядь. Ну, в теории-то красота: Модель, Вид, Контроллер — три кита, ёпта! А на практике получается пиздец, блядь, «Massive View Controller». Это когда твой UIViewController раздувается, как жаба на игле, и тащит на себе всё: и бизнес-логику, и работу с сетью, и парсинг JSON, и даже, сука, цвет кнопки решает. Чистая катастрофа, в рот меня чих-пых!

Смотри, в чём корень зла, блядь. Берём классический пример:

class UserViewController: UIViewController {
    // Проблема: контроллер делает слишком много
    func fetchData() { /* Сетевые запросы */ }
    func parseJSON() { /* Парсинг данных */ }
    func validateInput() { /* Валидация форм */ }
    func updateViews() { /* Вся работа с UI */ }
    func saveToDatabase() { /* Работа с CoreData */ }
}

Вот это, блядь, и есть тот самый монстр! Нарушается принцип единственной ответственности, как мать его. Контроллер должен только координировать, а он тут и швец, и жнец, и нахуй игрец. Удивление пиздец!

Ну и что делать, спросишь? А выкинуть эту хуйню и посмотреть на альтернативы, которые не доверия ебать ноль.

MVVM (Model-View-ViewModel), например. Суть проста, как три копейки: выносим всю мозгоёбную логику в ViewModel.

// Логика выносится в ViewModel
class UserViewModel {
    func loadUsers() { /* Бизнес-логика */ }
    func processData() { /* Преобразование данных */ }
}

// ViewController остаётся тонким
class UserViewController: UIViewController {
    var viewModel: UserViewModel!

    func updateUI() {
        // Только биндинг данных, никакой ебли с логикой
        nameLabel.text = viewModel.userName
    }
}

Контроллер становится лёгким, воздушным, почти невесомым. А ViewModel — это такая хитрая жопа, которая всё обрабатывает и подаёт на блюдечке.

А если хочется овердохуища структуры и чёткого разделения, то есть VIPER (View-Interactor-Presenter-Entity-Router). Это уже, блядь, для максималистов, которые любят всё по полочкам.

• Interactor — тут чистая бизнес-логика, ни намёка на UI.
• Presenter — берёт данные от Interactor'а и готовит их для показа, типа логика представления.
• Router — отвечает за навигацию, «пойди туда, не знаю куда».
• Entity — просто модели данных, тупые как пробка.
• View — тупо показывает то, что сказал Presenter, и шлёт ему сообщения о действиях юзера.

Ну а если ты не готов сразу на VIPER, блядь, то вот тебе простые советы, как не превратить контроллер в помойку:

1. Сетевые запросы — вынеси в отдельные сервисы, NetworkManager там какой-нибудь. Нехуй контроллеру с URLSession'ом возиться.
2. ViewModels — используй, как я уже говорил. Пусть они готовят данные для отображения.
3. Child view controllers — если экран сложный, дели его на части. Не пытайся впихнуть невпихуемое в один класс.
4. Координаторы (Coordinators) — пусть они рулят всей навигацией. Контроллер не должен знать, какой экран будет следующим, это пиздопроебибна.
5. Протоколы — твои лучшие друзья. Разделяй ответственность через них. Сделал протокол DataFetcher — и уже легче дышится.

Короче, суть в чём: твой ViewController — это не мусорный бак, куда можно скидывать всю логику подряд. Это тонкий дирижёр, который должен только махать палочкой, а не играть на всех инструментах сразу. Понял да? А то опять получится говнокод, который потом разгребать — терпения ноль ебать.