2011-06-27 2 views
2

У меня есть одноэлементный класс, который в основном поддерживает все мои HTTP-запросы. Так что это выглядит примерно так:В чем проблема с использованием singleton в приложении, которое использует много запросов HTTP?

Server <--> Singleton <---> view controllers --> views 

Плохо ли? Почему люди говорят мне, что синглтон ломает модульность? Я думаю, что это хороший способ реализации http-запросов, поскольку мне нужно сделать некоторые вещи с ответом JSON, и я не хочу, чтобы мои контроллеры представлений обрабатывали их.

ответ

1

Да, это хорошая идея. Фактически, ваш синглтон - это просто контроллер, который разговаривает с другими контроллерами. Это неплохое MVC.

Кроме того, это удобно, если у вас есть несколько форматов вывода (JSON, XML, HTML и т. Д.). Вы можете позволить Синглтону справиться с этим. Плюс это DRYer.

+0

+1 Для продвижения синглтонов. Не получил JSON-комментарий, хотя он * shoud * перешел в контроллеры представлений (слишком специфичные для синглтона, а не связанные с просмотром). – Eiko

+0

@Eiko мой ответ имел гигантское редактирование, я не уверен, что ваш комментарий по-прежнему применим. :) –

+0

Большое спасибо! Я собирался реорганизовать 60% моей базы кода ... Потому что синглтон становится все больше и больше, однако, если я разделить синглтон на несколько частей, мне придется отслеживать больше вещей ... (Что такое DRYer btw?) –

1

Я думаю, вы используете хороший подход, вместо создания нескольких экземпляров для работы с HTTP. Приятно иметь один шлюз.

Вы могли бы еще внутри есть еще два класса один для построения HTTP запросов, отправив соответствующий тип и другой будет обрабатывать ваши JSON синтаксического разбора вещи и передать хорошо структурированные данные в формате JSON для ваших ViewConrollers.

+0

+1 за хорошее предложение. –

+0

Ну, я действительно оставляю еще немного на диаграмме. Я использую SDK, который предоставляет HTTP-запрос, поэтому мой контроллер singleton не имеет отношения к этим вещам :) –