Шаблон проектирования MVC в сложном приложении для iPad: приемлем ли один жирный контроллер?

Question

Я создаю сложное приложение для iPad;думать об этом как записки.Для целей этого вопроса давайте рассмотрим страницу с двумя изображениями над ней.
В моем главном представлении отображаются мои документы в виде одного UIImage;это потому, что мне нужно сделать некоторые глобальные манипуляции над ними.Это мой DisplayView.
При редактировании мне нужно создать экземпляр EditorView с моими двумя изображениями в качестве подпредставлений;таким образом, я могу взаимодействовать с одним изображением (вращать его, масштабировать, перемещать).Когда происходит редактирование, я скрываю свой DisplayView и показываю свой EditorView.

. В приложении для iPhone я бы связывал каждый основной вид (то есть вид, заполняющий экран) с контроллером представления..
Проблема здесь в том, что есть только один контроллер вида;Я рассмотрел возможность передачи EditorView через контроллер модального представления, но это не вариант (там сложный макет с маской, покрывающей все и палитры над ней; перестройка в EditorView создаст дублирующий код).

В настоящее время EditorView включает некоторую логику (загружает данные из модели, вызывает некоторые подпредставления для точного редактирования, сохраняет данные обратно в модель);EditorView подпредставления также включают некоторую логику (я манипулирую изображениями и передаю их обратно на главную EditorView).Я чувствую, что эта логика больше относится к контроллеру.С другой стороны, я не уверен, что мой единственный контроллер представления настолько толстый - хорошая идея.

Какая лучшая реализация такой классовой структуры с добавлением какао?
Не стесняйтесь спрашивать разъяснения..
Приветствия.

Answer 1

Огромные жировые контроллеры в порядке.

Если необходимо, просто отломите некоторые «чисто логические части» и вставьте их в другие «вспомогательные классы». И используйте трюки, как категории, где вы можете.

Обязательно используйте HFC (огромный жирный контроллер), если это будет правильно.

Тогда, просто садись на свой инженерный байк и уберись от него!

Вы определенно не должны избегать правильной структуры, хорошей структуры, структуры, которую вы хотите, просто потому, что одна вещь будет слишком большой.

Просто уменьшите эту грандиозную вещь с помощью аутсорсинговых концепций, сходите с ума с категориями и т. Д. - каждый трюк в книге.

Моя вера!

Answer 2

Некоторые причины обернуть контроллер представления вокруг вашего представления:

• для использования его в Apple API, для которого требуется контроллер представления (всплывающие представления, модальные представления, панели навигации, панели вкладок,...)

• , потому что представление может быть невидимым на некоторое время, и поэтому имеет смысл очистить его в ситуациях нехватки памяти.Затем viewcontroller защищает данные, необходимые для выживания в таком цикле выгрузки-перезагрузки.

• , потому что вам нравится шаблон MVC

Я думаювторой маркер оправдывает viewcontroller для вашего представления редактируемого контента, а другой - для вашего представления не редактируемого контента.