Kā izmantot MVC arhitektūru, lai izvairītos no…

MVC (Model-View-Controller) iOS bieži noved pie "resniem" kontrolieru izveidi, jo tajos biznesa loģikas un attēlojamas loģikas izvietojuma dēļ. Šo problēmu var risināt ar šādiem pieejas veidiem:

Attēlojamas loģikas pārvietošana uz View: Izveidot īpašus UIView vai tabulas/kollekcijas šūnu elementus, kas ir atbildīgi par datu attēlošanu un galveno lietotāja darbību (piemēram, pogu nospiešanu šūnā). Kontrolieris tikai konfigurē View ar nepieciešamajiem datiem.

class MyCustomView: UIView {
    private let label = UILabel()

    override init(frame: CGRect) {
        super.init(frame: frame)
        addSubview(label)
        // constraints un cits konfigurācija
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    func configure(with text: String) {
        label.text = text
    }

    // UIControlEvents notikumu apstrāde, piemēram, ar addTarget
}

Biznesa loģikas pārvietošana uz Model vai atsevišķiem Service Object: Izveidot klases, kas ir atbildīgas par konkrētām operācijām (piemēram, tīkla, datu bāzes, datu validācijas darbiem). Kontrolieris deleģē šo uzdevumu izpildi šiem objektiem.

class UserService {
    func fetchUsers(completion: @escaping ([User]?, Error?) -> Void) {
        // tīkla pieprasījuma loģika
    }
}

class ProfileViewController: UIViewController {
    private let userService = UserService()

    override func viewDidLoad() {
        super.viewDidLoad()
        userService.fetchUsers { users, error in
            // UI atjaunināšana pēc saņemtajiem datiem vai kļūdas
        }
    }
}

Data Source un Delegate protokolu izmantošana: Implementēt UITableViewDataSource, UICollectionViewDataSource, UITableViewDelegate, UICollectionViewDelegate protokolus atsevišķās klasēs, nevis pašā kontrolierī. Kontrolieris tikai turēs šo klasu instances.

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
        // Datu ielāde un nodošana uz dataSource.update(users:)
    }
}

Coordinator Pattern izmantošana: Izveidot atsevišķus objektus, kas ir atbildīgi par navigāciju starp ekrāniem. Kontrolieris tikai zina, ka ir nepieciešams pāriet uz nākamo soli, bet nezina, kurš kontrolieris būs nākamais.

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()
        // konfigurēt deleģātu, dataSource un citus parametrus
        navigationController.pushViewController(usersVC, animated: false)
    }

    func showUserDetails(user: User) {
        let userDetailsVC = UserDetailsViewController(user: user)
        navigationController.pushViewController(userDetailsVC, animated: true)
    }
}

Šie pieejas veidi ļauj samazināt kontroliera slodzi, padarot to "plānāku" un koncentrējoties uz View dzīves cikla pārvaldību un mijiedarbības organizēšanu starp Model un View, nevis uz visu lietojumprogrammas loģikas izpildi.

Kā izmantot MVC arhitektūru, lai izvairītos no kontroliera pārslodzes?