Модель владения объектом и MVC в Какао / iOS / iPhone - PullRequest
9 голосов
/ 09 июля 2011

Я пытаюсь понять, как лучше реализовать шаблон проектирования Model-View-Controller.

Какой объект должен «владеть» объектом Model? Должен ли единственный Контроллер создавать (иметь) объект Model?

Вот пример сценария:

У меня есть UITabbarController, содержащий два UIViewController (controllerA и controllerB). Очевидно, что ни один из этих контроллеров не владеет друг другом. У меня есть объект Model, который содержит некоторые данные, а также выполняет некоторые сетевые операции. Контроллер A и контроллер B должны иметь возможность вносить изменения в объект Model. controllerB должен знать, когда были внесены изменения в объект Model (контроллером А или возвращены результаты сетевой активности). Из недавнего прочтения:

  • Мне нужно KVO между объектом Model и контроллером B?
  • Должен ли объект Model быть одноэлементным? Чтобы оба контроллера могли его модифицировать?
  • В более простых приложениях у viewController был объект Model. Есть ли способ для одного контроллера создать экземпляр объекта Model, но для других контроллеров иметь доступ на запись в него?
  • Я также читал об использовании делегата приложения для владения объектом Model и разрешении контроллерам получать доступ через экземпляр общего ресурса делегата приложения. Это кажется уродливым - использование одиночного делегата приложения для глобального доступа к моему объекту Model. Разве не лучше было бы просто сделать объект моей модели синглтоном?
  • Я видел, как кто-то на SO дал эту ссылку на iPhoneDevSDK, но причины его метода ускользнули от меня. Опять же, разве это не привлекает делегата приложения к чему-то, что должно быть просто одноэлементным?

В основном, есть ли другой способ для двух контроллеров получить доступ (записать) к одной модели, кроме как через модель, являющуюся одиночной?

Кроме того, когда Контроллер владеет другим Контроллером (например, в UINavigationController, когда контроллер корневого представления создает другой контроллер представления для размещения поверх него самого), лучшим способом для совместного использования Модели будет использование корневого контроллера представления Модель, и передайте его следующему контроллеру представления, прежде чем поместить его в стек навигации)?

Ответы [ 2 ]

8 голосов
/ 09 июля 2011

Хранение глобальных объектов в AppDelegate становится по-настоящему уродливым по мере масштабирования вашего проекта.

Задайте себе вопрос: какова взаимосвязь между этими объектными объектами и другими объектами в моем приложении?Является ли отношение 1-к-1 или 1-к-n.Если вам нужна только одна модель для доступа к различным объектам, тогда используйте одноэлементный подход.Если вам нужен один объект, чтобы иметь ровно одну модель, сохраняйте указатель на него в этом объекте.

При столкновении с другими, но вычислительно правильными, проектными альтернативами следует учитывать несколько областей

  1. Какой подход минимизирует количество строк кода?
  2. Какой подход вызывает наименьшее количество связей и семантических связей?
  3. С точки зрения программиста, новичка в проекте, такой подход легче понятьподдерживать и усложнять непреднамеренное введение ошибок.

Если вы начнете внедрять глобальные модели в AppDelegate, вы в конечном итоге создадите монолитный класс, который будет трудно понять и труднее поддерживать.Если вы создаете указатель на модель в каждом контроллере, вы должны передавать ссылку на эту модель каждый раз, когда создается новый элемент управления, и он должен передавать указатель на любой нужный объект, который он создает.По сути, вы создали каскадный водопад, передающий тот же указатель, раздутый файл интерфейса и конструктор.Представьте, что вместо 1 модели вам нужно отслеживать 5 модельных объектов.Имеет ли смысл для объектов иметь 5 указателей на 5 моделей, которые необходимо передавать конструктору каждый раз?Вот как сделать ваши проекты ошибочными и не поддерживаемыми.

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

Относительно KVO: Это зависит от того, чего вы пытаетесь достичь.Я приведу пример, где КВО является полезным.Предполагается, что у вас есть объект модели, хранящий пользовательские настройки приложения.

@interface SettingsModel
.....
@property (nonatomic, retain) UIColor * backgroundColor;
@end

Другие представления в приложении должны немедленно обновлять свой цвет фона при каждом изменении этих настроек.Это можно легко решить с помощью KVO:

[[SettingsModel getInstance] addObserver:self forKeyPath:@"backgroundColor" options:0 context:nil];


- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context {
     if ([keyPath isEqualToString:@"backgroundColor"]){
         self.view.backgroundColor = [[SettingsModel getInstance] backgroundColor];
     }
}
0 голосов
/ 09 июля 2011

На модель могут ссылаться несколько контроллеров.Чтобы получить представление об основах модели-представления-контроллера в разработке для iPhone, просмотрите первые 2 лекции курса по разработке для iPhone в Стэнфорде (доступны бесплатно в iTunesU, см. Информацию в Стэнфорде по адресу http://www.stanford.edu/class/cs193p/cgi-bin/drupal/)кажется, есть больше способов информировать контроллеры об обновлениях вида и / или модели.

Я не уверен, почему вы застряли на Singleton, и я также не вижу проблемы в создании Singletonмодельный объект.Я думаю, что вы также должны учитывать безопасность потоков и утечки памяти.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...