Кто отвечает за инициализацию модели из удаленных источников

Я знаю, что я отвечаю за это в коде, но в объектно-ориентированном и MVC смысле, кто действительно должен загружать модель. У меня есть модель для представления RSS-каналов, которые загружаются с URL-адреса. Модель действительно тонкая, и контроллер управляет загрузкой и разбором XML, а затем передает его модели. Лучше сделать так или пусть модель сама инициализируется?

Код в контроллере, который управляет получением фидов, выглядит примерно так:

// EntriesController.m
- (void)getFeedsFromWeb {
    Parser *parser = [[Parser alloc] init];
    [parser addListener:self];
    Downloader *downloader = [[Downloader alloc] initWithParser:parser];
    [downloader getFeed:@"http://www.example.com/rss"];
    [parser release];
}

- (void)notify:(Feed *)aFeed {
    self.feed = aFeed;
    [self updateView];
}

Загрузчик начинает загрузку и накопление данных ответа и передает их синтаксическому анализатору. Когда синтаксический анализатор завершен, он вызывает метод обратного вызова notify:(Feed *)feed в классе EntriesController, который обновляет свою модель.

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

// Feed.h
- (void)initWithContentsOfURL:(NSURL *)feedURL
- (void)initWithContentsOfDatabase:(sqlite *)database

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


iphone model design-patterns model-view-controller
person Anurag    schedule 24.09.2009    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Является ли «EntriesController» здесь контроллером представления или действительно контроллером модели? Если это контроллер представления, я бы рекомендовал поместить логику в класс Model. Настоящая работа контроллера представления состоит в том, чтобы управлять представлением и координировать свои действия с Моделью; не для реального управления моделью.

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

Мой опыт, вообще говоря, таков, что в мире MVC вы, как правило, пишете два из них, а Apple (или XIB) предоставляет другой. Если вы пишете все три самостоятельно, у вас может быть задействовано слишком много слоев.

person Rob Napier    schedule 25.09.2009
comment
EntriesController действительно является контроллером представления, контроллером табличного представления. Если бы для этой модели было несколько представлений, код инициализации модели реплицировался бы везде. И более того, модель непригодна для использования без вью-контроллера. Спасибо, Роб, теперь я вижу огромный недостаток в своем дизайне. - person Anurag; 25.09.2009