архитектура приложения для iPhone

Question

Учитывая хороший дизайн, лучше ли каждому контроллеру представления управлять своим собственным подключением / сетью / загрузкой или централизовать его в делегате приложения или в отдельном объекте?

Контекст:

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

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

Идеи / мнения?

ТИА.

Answer 1

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

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

В конце концов, я думаю, что, вероятно, для доменных объектов лучше всего это обрабатывать, а не для контроллеров представления. Например, в viewWillAppear вы получаете или создаете экземпляр объекта домена и запускаете метод getData, который имеет контроллер представления в качестве делегата. Весь запрос / анализ выполняется в вашем доменном объекте, и когда он завершен, он отправляет вашему контроллеру представления сообщение getDataDidFinish или что-то в этом роде.

Answer 2

Когда я сталкиваюсь с такой ситуацией, я стремлюсь создать объект, который обрабатывает все сетевые вещи для меня. Таким образом, я получаю возможность писать код вроде:

[netObj getXML:somePlace];

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