Категории и примеры классов Model-View-Controller
В Model-View-Controller (MVC) каждый класс должен быть спроектирован для соответствия одной из этих трех категорий.При этом вы можете избежать связывания классов и создать гораздо более гибкий код.
Классы моделей. Классы этой категории должны представлять модель данных приложения.Если приложение представляет собой игру, то классы, которые представляют игрока, врагов, макеты уровней, сохраненные данные (например, табло) и так далее. Но эти классы должны быть ограничены только хранением данных, которые представляют эти объекты, и логикой, стоящей за ними.Например, если это гоночная игра, класс «Автомобиль» должен быть частью модели, и он должен представлять все свойства автомобиля (например, его скорость, ускорение, разворот и т. Д.).Этот класс должен также включать в себя всю необходимую логику для автомобиля, например логику, которая определяет, как автомобиль должен двигаться (например, ускорение и торможение, поворот), и что должно произойти в случае столкновения и так далее.Этот класс 'Car' должен note определять, как автомобиль представлен пользователю.Также этот класс не должен включать какую-либо логику приложения.Следует полностью описать, что это за автомобиль.
Просмотр классов. Классы этой категории должны представлять способ, которым приложение представляет модель пользователю.Как и в предыдущем примере, примерами классов, попадающих в эту категорию, будут «MainMenu», «ScoreBoardView» и «RenderingEngine».Класс «MainMenu» точно знает, как отобразить список параметров для пользователя и как выглядеть действительно красиво.Он также знает, что когда выбран один из параметров, он должен слегка изменить свой внешний вид, например, кнопка с надписью «нажата».Тем не менее, этот класс не знает, какую логику делать при нажатии кнопки.Это работа контроллеров классов.Таким образом, классы представлений просто сообщают соответствующему контроллеру, что пользовательский интерфейс взаимодействовал с пользователем (путем вызова некоторого метода контроллера или отправки уведомления).Подробнее об этом в разделе «Контроллеры».
«ScoreboardView» также знает, что когда ему передается словарь (класс модели) строк и чисел (имена и оценки игроков), он должен представлять их определенным образом,возможно в столе.Он не знает, как обновить словарь, и как рассчитать средний балл.Если он хочет получить больше информации, он должен спросить у контроллера.Задача контроллера - выяснить способ получения информации.
Наконец, для этого раздела «RenderingEngine» - это класс представления, поскольку он берет модель и создает для нее визуальные элементы.И это все.RenderingEngine запрограммирован, чтобы знать, как отображать автомобиль, и что, если автомобиль настроен на то, чтобы находиться в определенном месте, его следует рисовать в этом месте, или, если автомобиль столкнулся, то его нужно рисовать с прогибом.Но опять же, он не знает, как обновить положение автомобиля, скорость и т. Д.
Классы контроллера. Наконец, как я уже ранее немного упоминалКонтроллеры - это классы, которые объединяют все и обеспечивают поток и контроль для вашего приложения.Люди называют классы контроллеров «мозгом» приложения, потому что они принимают решения на основе пользовательского ввода (который направляется через классы представления) и модели данных (которая доступна через классы модели).Классы контроллера управляют потоком приложения. Они переносят пользователя из «главного меню» на «экран выбора автомобиля», на «гоночную трассу», в «гонку», на «экран табло» и так далее! Они вносят изменения в модель через классы и обеспечивают обратную связь об изменениях в классах представления, чтобы эти классы могли представлять текущее состояние приложения пользователю. Контроллеры эффективно связывают модель и представление вместе, обеспечивая в то же время логику приложения и рабочий процесс программы. Этот рабочий процесс программы может также включать обработку проблем, когда входные данные, взятые из представления, не соответствуют модели. Представление очень мало знает о модели и не может обеспечить необходимые проверки - это одна из задач контроллера. По этой причине обычно считается плохой практикой напрямую связывать классы представления с классами модели. Из трех типов классов контроллеры, как правило, являются наименее взаимозаменяемыми, но на практике именно классы представлений и моделей вы хотели бы обменять чаще всего.
Выводы. Шаблон проектирования модель-представление-контроллер позволяет разработчикам логически организовывать свою работу и компоненты своих приложений. Когда используется парадигма модель-представление-контроллер, она сохраняет гибкость, поскольку любой из трех компонентов может быть заменен, при условии, что модуль замены придерживается того же протокола, с которым другие два компонента могут взаимодействовать. (Когда я говорю «протокол», этот дизайн может быть реализован с использованием наследования, или для некоторых случаев лучше использовать фактическое объявление протокола и убедиться, что классы подтверждают соответствующие протоколы.) Прекрасным примером этого является то, что многие приложения, написанные для Mac, можно легко перенести на iOS, потому что единственное существенное различие между двумя платформами заключается в уровне пользовательского интерфейса, что вполне понятно, учитывая, что интерфейс для Mac традиционно представляет собой большой экран, с которым пользователь взаимодействует через клавиатура и мышь, с другой стороны, интерфейс для iOS состоит из гораздо меньшего экрана, с которым пользователь взаимодействует.
Дополнительное чтение. Страница википедии (конечно!), MVC в документации для разработчиков Apple , 'Шаблоны дизайна какао' Эрика М. Бак .
Я пытался сделать это объяснение достаточно общим для всех платформ, сред и языков. В разработке для iOS дизайн MVC считается настолько важным, что вам придется очень усердно работать с фреймворками, чтобы избежать использования MVC. Существует четкое различие между классами представления (UIView, UITableView, UIAlertView, UIImageView и т. Д.) И классами контроллера (UIViewController, UITableViewController, UINavigationController и т. Д.) И остальными классами модели (NSString, NSDate, NSManagedObjectContext, UIImage и т. Д.). ). Каждый класс явно относится к одной из этих трех категорий, что обеспечивает повторное использование кода и невероятную гибкость при разработке приложения.
Если говорить конкретно о вашем вопросе, ваш AppDelegate попадет в категорию классов контроллеров. Он обеспечивает контроль над ключевыми событиями вашего приложения. Когда приложение запускается, когда оно выходит, когда оно входит в фоновый режим и так далее. В вашей программе должно быть место, где нужно что-то делать на этих событиях, и именно здесь это должно быть реализовано.
Надеюсь, это поможет. Я также настоятельно рекомендую проверить бесплатное видео сеанса WWDC2010 по парадигме Model-View-Controller.