Как выбрать, какой код вставлять в представление, а не в ViewController?

В Xcode шаблон служебного приложения создает проект с:

MainView, MainViewController

и

FlipsideView, FlipsideViewController

В моем приложении два представления соответствуют основному пользовательскому интерфейсу и экрану настроек. Очевидно, я хочу, чтобы настройки отражались в основном пользовательском интерфейсе и сохранялись на диске для запоминания настроек. Я знаю, как это сделать.

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

Есть ли какое-то практическое правило при принятии решения о том, где разместить большую часть моей функциональности?


iphone cocoa-touch uiviewcontroller
person willc2    schedule 28.06.2009    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Один из способов решить: если ваше приложение получает предупреждение о нехватке памяти, поведение по умолчанию заключается в том, что любое представление, которое в настоящее время не отображается, может быть уничтожено. Это означает, что если у вас есть какая-либо информация о состоянии, которую вы не можете легко воссоздать, вам лучше не держать ее в поле зрения.

Так что это зависит от того, что делает основная часть вашей функциональности: если она поддерживает информацию, созданную пользователем, она должна находиться в контроллере представления.

person David Maymudes    schedule 28.06.2009

arrow_upward
2
arrow_downward

Если вы хотите быть сторонником MVC, такие вещи, как переключение представлений и обработка событий, должны выполняться контроллером, а код построения представлений - в представлении.

Но можно поместить в представление некоторую логику приложения, если вы едины во всем приложении.

person Marco Mustapic    schedule 28.06.2009
comment
Я согласен с тем, что обычно только код построения представления относится к классу представления. И часто код построения представления не требуется, поэтому вы можете полностью избавиться от класса представления. - person Kristopher Johnson; 28.09.2009

arrow_upward
1
arrow_downward

В StackOverflow уже есть несколько вопросов, касающихся контроллера-представления-модели. Например, см. Что входит в контроллер в MVC?.

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

person Bob Whiteman    schedule 28.06.2009