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

Question

Я некоторое время удивлялся, после того, как спросил разных людей, и ни один из них не дал то, что я назвал бы «хотя бы немного конкретным ответом»:

Вопрос:

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

В приложениях для iPhone (и Какао) у нас есть то, что мы называем «делегатом приложения», который в основном запускает наше приложение и устанавливает контроллеры, а также обрабатывает события UITouch.

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

Пример:

У вас есть делегат приложения, который содержит ссылку на контроллер представления вашего приложения. Если мое приложение будет использовать класс модели A (который является классом демона веб-сервера) и класс B, в котором хранятся данные, запрашиваемые этим веб-сервером.

Где бы вы, ребята, хранили ссылки на А и Б? (Делегат приложения? Просмотреть контроллер? Оба?)

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

Answer 1

Соблазнительно поместить все в AppDelegate, но если вы начнете это делать, то ваш AppDelegate будет полон ссылочных хаков. Если вы делаете строгий MVC, то у вас должно быть 3 вещи:

• Модель
• Контроллер представления (только для логики представления)
• Контроллер (для координации между видом и моделью)

Так, например, у меня есть модель Foo и контроллер Foo. Я бы имел:

• Foo.m (модель)
• FooViewController.m (отображает Foo)
• FooController.m (управляет логикой)

И, наконец, чтобы ответить на ваш вопрос, я бы сохранил свои ссылки на Foo в контроллере foo. Мне нравится использовать синглтоны для моих контроллеров, но это только я. Если вы используете синглтон, вы можете просто сделать что-то вроде этого: [[FooController sharedInstance] listOfFoos], чтобы получить свой Foo's

Answer 2

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

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

Answer 3

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

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

Итак, является ли приложение Delegate контроллером? модельный класс? ни один из двух?

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

Где бы вы, ребята, хранили ссылки на А и Б?

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

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

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

Я бы настроил ваш пример приложения так:

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

Непонятно в вопросе, какова цель класса В.

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

Answer 4

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

Answer 5

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

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