Как использовать архитектуру MVC, чтобы избежать перегрузки контроллера?

MVC (Model-View-Controller) в iOS часто приводит к "толстым" контроллерам из-за размещения в них бизнес-логики и логики представления. Для решения этой проблемы можно использовать следующие подходы:

• Вынос логики представления в View: Создание кастомных UIView или ячеек таблиц/коллекций, которые отвечают за отображение данных и обрабатывают базовые действия пользователя (например, нажатия кнопок внутри ячейки). Контроллер лишь конфигурирует View нужными данными.

  class MyCustomView: UIView {
      private let label = UILabel()
  
      override init(frame: CGRect) {
          super.init(frame: frame)
          addSubview(label)
          // Настройка constraints и т.д.
      }
  
      required init?(coder: NSCoder) {
          fatalError("init(coder:) has not been implemented")
      }
  
      func configure(with text: String) {
          label.text = text
      }
  
      // Обработка событий UIControlEvents, например черезaddTarget
  }
  

• Вынос бизнес-логики в Model или отдельные Service Objects: Создание классов, отвечающих за конкретные операции (например, работа с сетью, базой данных, валидация данных). Контроллер делегирует выполнение этих задач этим объектам.

  class UserService {
      func fetchUsers(completion: @escaping ([User]?, Error?) -> Void) {
          // Логика сетевого запроса
      }
  }
  
  class ProfileViewController: UIViewController {
      private let userService = UserService()
  
      override func viewDidLoad() {
          super.viewDidLoad()
          userService.fetchUsers { users, error in
              // Обновление UI на основе полученных данных или ошибки
          }
      }
  }
  

• Использование Data Source и Delegate Protocols: Реализация протоколов UITableViewDataSource, UICollectionViewDataSource, UITableViewDelegate, UICollectionViewDelegate в отдельных классах, а не в самом контроллере. Контроллер будет лишь владеть экземплярами этих классов.

  class UsersTableViewDataSource: NSObject, UITableViewDataSource {
      private var users: [User] = []
  
      func update(users: [User]) {
          self.users = users
      }
  
      func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
          return users.count
      }
  
      func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
          let cell = tableView.dequeueReusableCell(withIdentifier: "UserCell", for: indexPath)
          let user = users[indexPath.row]
          cell.textLabel?.text = user.name
          return cell
      }
  }
  
  class UsersViewController: UIViewController {
      @IBOutlet weak var tableView: UITableView!
      private let dataSource = UsersTableViewDataSource()
  
      override func viewDidLoad() {
          super.viewDidLoad()
          tableView.dataSource = dataSource
          // Загрузка данных и передача в dataSource.update(users:)
      }
  }
  

• Применение Coordinator Pattern: Создание отдельных объектов, отвечающих за навигацию между экранами. Контроллеры знают только о том, что нужно перейти к следующему шагу, но не о том, какой именно контроллер будет следующим.

  protocol AppCoordinator: AnyObject {
      func start()
      func showUserDetails(user: User)
  }
  
  class MainAppCoordinator: AppCoordinator {
      private let navigationController: UINavigationController
  
      init(navigationController: UINavigationController) {
          self.navigationController = navigationController
      }
  
      func start() {
          let usersVC = UsersViewController()
          // Настройка делегата, dataSource и т.д.
          navigationController.pushViewController(usersVC, animated: false)
      }
  
      func showUserDetails(user: User) {
          let userDetailsVC = UserDetailsViewController(user: user)
          navigationController.pushViewController(userDetailsVC, animated: true)
      }
  }
  

Эти подходы позволяют разгрузить контроллер, делая его более "тонким" и сосредоточенным на управлении жизненным циклом View и координации взаимодействия между Model и View, а не на выполнении всей логики приложения.