Как стать автором
Обновить

Комментарии 18

Спасибо, интересный материал.
Говоря про VIPER — мне кажется, многие уже реализуют подобные архитектурные решения, и не только в iOS, при этом продолжая называть это MVC.
Богдан, спасибо за материал. Он вполне неплох, как ориентир. Однако примеры, приведенные здесь, к сожалению, нерелевантны. Усложнение (или просто изменение) архитектуры всегда должно быть направлено на решение проблем, а не прои
Извините, к сожалению, не очень удобно ведет себя моб. приложение хабра, случайно отправил незаконченное сообщение.
В общем, пример, приведенный вами, слишком мелковат для того, чтобы увидеть реальную проблему, и не понятно, что конкретно решают переходы на ту или иную архитектурную "парадигму".
Примеры, на самом деле, очень маленькие, и проблему в них никак не увидеть. А статья, все-таки, обзорная, и полезная, в первую очередь, тем, кто сам заметит проблемы с Епловским MVC и захочет попробовать использовать что-то другое.
Есть какая-нибудь литература по паттернам, применимым к iOS? Не так давно занимаюсь разработкой под эту платформу. Apple'овская документация мне понравилась больше, чем «iOS Programming. Big Nerd Ranch». Сейчас читаю «Effective Objective C 2.0». Мне понравилась статья, хотел бы больше узнать по данной теме.
Есть такая книга со слегка надуманными примерами. И вот эту статью можно прочитать для общего развития.
Практически в каждой статье о шаблоне MVC в iOS делают одну и туже ошибку:
Изначально авторы приводят в качестве примера ТТУК и вместо того, чтобы исправить нарушение шаблона MVC, начинают искать решение в использование MVVM, VIPER и т.п.
В MVC, контроллер не должен знать детали реализации представление, а тут автор считает правильным конфигурировать ячейки таблицы именно в контроллере — из-за такой реализации контроллер и представлени жестко зависят друг от друга, и именно такой подход нарушает шаблон MVC и превращают контроллеры в ТТУК. Есть простое правило: представьте что вам нужно полностью заменить представление, при этом данные, бизнес логика, обработка действий пользователя остаются неизменными, например, вместо таблицы отображать данные в виде коллекции — если в этом случаи вам прийдется полностью менять контроллер — вы нарушили шаблон.
Также передача объекта user в представление userCell никак не нарушает шаблон — здесь user — это пассивная модель, которая отвечает за хранение данных и представление может и должно знать о ней. В MVC представление может зависить от пассивной модели, модель не может зависить от представления.
Вся проблема в том, что все помешались на MVC, любую архитектуру пытаются решить именно этим паттерном. Вставляют туда, где она изначально не нужна. Самый лучший совет — почитать перед сном «Банду четырёх» а на утро все забыть, и спроектировать как душа пожелает
Проблема не только в том, что помешались на MVC, а в том, что еще и этот MVC они не понимают или понимают не правильно. Полностью согласен с комментарием выше(коммент). Очень много авторов, кто пишет о паттернах и не понимает MVC, так что уж говорить об остальных разработчиках
Интересно, как грамотно применить тот же MVP, когда представление — это не лейбл с кнопкой, а Collection View с несколькими секциями и хидером еще каким-нибудь хитрым.
Тут некоторые не понимают, что это другой MVC. Автор в самом начале написал об этом. Стоит, наверное выделить жирным и подчеркнуть: Эппловский вариант MVC — не то же самое, что классический MVC. И это не неправильный, а отличающийся от привычного в вебе MVC.
https://developer.apple.com/library/mac/documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html — посмотрите на первую картинку. Посмотрите несколько раз.
Контроллер в их шаблоне является посредником между вью и моделью:
A major purpose of view objects is to display data from the application’s model objects and to enable the editing of that data. Despite this, view objects are typically decoupled from model objects in an MVC application.

A controller object interprets user actions made in view objects and communicates new or changed data to the model layer. When model objects change, a controller object communicates that new model data to the view objects so that they can display it.

https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/
A view controller acts as an intermediary between the views it manages and the data of your app.

Так что все комментарии в духе «в MVC должно быть вот так» тут никак не уместны. Пишу это не столько ради бьющих себя пяткой в грудь, сколько ради начинающих разрабатывать под iOS. Читайте документацию и составляйте собственное мнение.
Впервые за последнее время встречаю так хорошо отредактированный и оформленный материал. Спасибо, приятно читать.
Спасибо за статью,
Интереует ваше мнение по ахитектуре MVC:
Как разделить контроллер и модель данных, кто из них должен посылать запрос серверу:
1) Можно повесить это на модель, но при этом нужно показывать индикатор активности(крутилку) пользователю и блокировать какие-то кнопки — а это делает контроллер.
2) Другой вариант – это послать запрос на контроллере, и полученные данные передать модели в блоке завершения.
В MVC в Модель засуньте как можно больше бизнес логики. Тоесть несомнено первый вариант лучше. Возможно вам также поможет вот эта статья: Do MVC like it’s 1979
Согласна, чем больше можно убрать из контроллера, тем лучше. Даже применяя чистое MVC, можно добиться неплохой читабельности кодов. А если еще и VIPER добавить, то можно убрать дублирующие коды. Конечно, хорошо планировать архитектуру заранее, чтобы потом не возится с переделками. Но когда нет постановки задачи и нет трудовых ресурсов — без переделок никак не получается.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре , чтобы оставить комментарий