Ответ
MVC часто нарушает SOLID, особенно принцип Single Responsibility. ViewController в iOS становится "массивным", так как объединяет логику представления и бизнес-логику. Это нарушает SRP (класс должен иметь одну причину для изменения).
Пример нарушения:
class ProfileViewController: UIViewController {
// Нарушение: и данные, и обновление UI в одном классе
func fetchUserData() {
NetworkService.fetchUser { [weak self] user in
self?.updateUI(with: user)
self?.saveToDatabase(user)
}
}
private func updateUI(with user: User) {...}
private func saveToDatabase(_ user: User) {...}
}Также часто нарушается Dependency Inversion - ViewController напрямую зависит от конкретных сервисов. Решение - разделение на отдельные компоненты (Presenter, Interactor) как в VIPER или MVVM.
Ответ 18+ 🔞
Ну ты посмотри на эту дичь, блядь! MVC, говоришь? Да это ж классический пример, как из хорошей идеи сделать пиздец. Single Responsibility Principle? Да его тут и не пахнет, ёпта!
Смотри, в чём прикол: в теории контроллер — это такой посредник, связка. А на практике получается, что наш уважаемый ViewController превращается в этакого монстра, который тащит на себе всё: и данные вытащить, и UI обновить, и в базу запихнуть, и чайку тебе заварить, блядь! Одна причина для изменения? Да у него их овердохуища! Захотел поменять апишку — лезь в него. Захотел другую вёрстку — опять в него. Это ж чистой воды нарушение, ёбаный насос!
Вот смотри на этот код, просто пиздец:
class ProfileViewController: UIViewController {
// Нарушение: и данные, и обновление UI в одном классе
func fetchUserData() {
NetworkService.fetchUser { [weak self] user in
self?.updateUI(with: user)
self?.saveToDatabase(user)
}
}
private func updateUI(with user: User) {...}
private func saveToDatabase(_ user: User) {...}
}Ну что это такое, а? Кто это писал? Человек или мартышлюшка с клавиатурой? Он тут и сетевой запрос дергает, и UI рисует, и в базу пихает! Мало того, что он за всё отвечает, так он ещё и жёстко привязан к конкретной NetworkService. Захотел заменить её на мок для тестов — хуй тебе, а не замена. Dependency Inversion Principle тоже в рот берунчик!
И знаешь, в чём главная беда? Когда этот контроллер разрастётся до 1000 строк, там уже никто ни хуя не понимает. Добавить новую фичу — это как минное поле пересечь. Одно изменение в одном месте — и всё, пиздец, полетели кони, народ, грибы!
Что делать-то, спрашиваешь? Да раздербанить эту кучу, блядь! Вынести логику куда подальше. Пусть ViewController только показывает, что ему сказали, и тыкает в кнопки. Вся бизнес-логика — в отдельный Interactor или Service. Данные для UI готовит Presenter или ViewModel. А за зависимости отвечает какой-нибудь Assembly или Dependency Container, чтобы не создавать их внутри, а получать снаружи. Как в тех же VIPER или MVVM.
А то так и живём: написали кучу-малу, а потом сидим и ебёмся с легаси, волнение ебать, терпения ноль ебать. Архитектура, мать её!