В MVC, куда Вы помещаете ссылки на свою модель Classes?

В своих приложениях я обычно переименовываю класс AppDelegate в AppController, если это помогает лучше концептуально объяснить вещи. Контроллер вашего приложения отвечает за создание и / или настройку контроллера модели (который управляет вашей коллекцией объектов модели) и контроллеров окон или представлений, настройку ссылок между ними, если это необходимо, и вызов методов на этих контроллерах в ответ на методы делегата NSApplication или методы действий высокого уровня из главного меню. В зависимости от сложности вашего приложения у вас также могут быть дополнительные контроллеры моделей или представлений, которые создаются вне вашего контроллера приложения.

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

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

Где в приложении для iPhone должны храниться ссылки на его классы моделей (с использованием подхода MVC) ?

Уровень контроллера хранит ссылки на уровень модели.

Так является ли приложение делегатом контроллера, класса модели, ни один из двух ?

Делегат приложения является контроллером.

Где вы храните ссылки на A и B?

A и B - это классы моделей, которые обычно создаются и принадлежат слою контроллеров.

Мне бы очень хотелось узнать, как бы вы, ребята, использовали mvc, чтобы собрать это приложение, которое использует только один вид.

Назначение уровня контроллеров - позволить слоям модели и представления быть автономными. Модель ничего не должна знать о контроллерах и слоях представления. Вид не должен ничего знать о контроллерах или слоях модели. Задание контроллера - быть двусторонним адаптером к модели с одной стороны и представлению с другой.

Я бы установил ваше примерное приложение следующим образом:

• UIA-приложение делегирует AppDelegate.
• Если работа вашего класса сервера (A) является простой:
  • AppDelegate создает и владеет экземпляром(ами) класса сервера A.
• Если работа вашего класса сервера (A) является сложной:
  • Создайте выделенный класс контроллера (C) для управления сервером.
  • AppDelegate создает и владеет экземпляром(ами) класса C. По одному экземпляру (C) для каждого экземпляра (A).
  • Каждый экземпляр класса C создает и владеет одним экземпляром класса A.
• AppDelegate создает и владеет экземпляром вашего класса ViewController, который загружает и владеет вашим видом.

В вопросе неясно, для чего нужен класс B.

• Если это кусок данных, который предназначен только для использования A (например, данные конфигурации или статические данные веб-сайта), то я бы создал его и стал владельцем сервера (A).
• Если это данные, которые создаются во время работы сервера и должны быть отображены в виде, то вы, вероятно, захотите что-то вроде:
  • Мутирующий массив, принадлежащий A, для хранения экземпляров B.
  • Другой класс контроллера (D) для обращения к этому массиву и действия в качестве источника данных/делегата для вашего вида.

Я нахожу, что в большинстве случаев AppDelegate предоставляет хорошее место для размещения некоторой базовой функциональности (например, фонового изображения, которое вы хотите применить в каждом контроллере), но что вы захотите иметь дополнительные контроллеры и код модели в другом месте. NavController или rootController часто помещаются в качестве свойств AppDelegate.

Итак, я бы сказал, что это где-то между "ни тем, ни другим" и "контроллером", но больше склоняюсь к "ни тем, ни другим". Определенно не "модель"!