Где файл AppDelegate вписывается в MVC?

Я изучаю программирование iPhone/iPad. Я считаю, что понимаю концепцию MVC; с чем мне сложно, - это понять, как некоторые файлы в обычном приложении iPhone/iPad подходят к MVC.

При создании нового приложения с использованием шаблона "Просмотр на основе приложения" создается файл AppDelegate.m и AppDelegate.h.

Является ли это файлом Model, View или Controller? Я предполагаю, что на самом деле это не так. Мне хотелось бы видеть диаграмму или блок-схему процесса, которая показывает, к какой категории относится каждый файл в приложении.

Ответ 1

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

Я бы не стал слишком беспокоиться о том, чтобы классифицировать каждый файл в MVC, некоторые просто не подходят идеально, если вообще.

Ответ 2

Делегат приложения является объектом контроллера. По умолчанию он является владельцем и контроллером главного окна - который является видом - в приложении iOS. Делегат приложения получает сообщения от объекта, представляющего - или моделирования, - самого приложения (экземпляр UIApplication). Он посредничает между объектом приложения, который является точкой контакта между приложением и системой, и отображением приложения.

Ответ 3

Я рассматриваю AppDelegate как контроллер, потому что этот вид кода

- (BOOL)application:(UIApplication *)application 
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
// Override point for customization after application launch.

self.window.rootViewController = self.viewController;
[self.window makeKeyAndVisible];
[application setStatusBarHidden:YES withAnimation:NO];
return YES;
}

AppDelegate - это место для установки ссылок между моделями и представлениями.
В AppDelegate вы размещаете код, специфичный для вашего приложения.
View и Model должны быть в состоянии жить в другом приложении (как класс UIView), потому что они не являются специфичными для приложения.
Это более очевидно в приложении Mac Desktop, в этом делетете еще больше.

Ответ 4

Это старый вопрос, но сегодня я задал себе тот же вопрос. Я считаю, что класс AppDelegate не может быть классифицирован как только Контроллер. Он управляет Window и устанавливает свой корневой контроллер, поэтому его можно классифицировать как View Controller (обратите внимание: UIWindow наследует UIView). Но он также выполняет больше задач, связанных с моделью, например, сохранение данных при завершении работы приложения. Поэтому его можно считать контроллером модели или связанным с уровнем доступа к данным.

Он также отвечает за обработку URL-адреса. Это может вызвать изменение View, но также обязательно потребует связанных с Model задач, таких как синтаксический анализ, сохранение, обновление, аутентификация и т.д. Если View/Model привязаны через KVO, просто обновление модели может привести к обновлению требуемых представлений. Я чувствую, что это будет намного лучше. Кроме того, тот факт, что по умолчанию весь стек Core Data добавлен в AppDelegate, он отвлекает его от того, что он связан только с View.

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

Поскольку AppDelegate является точкой входа в приложение (для разработчика), имеет смысл говорить об этом с точки зрения приложения. Приложение заканчивается, приложение вводит фон и т.д. Мы говорим об этом приложении как о Model.