LINUX.ORG.RU

Вопрос по архитектуре приложения

 , , ,


0

2

Здравствуйте.

Помогите найти верное решение.
Есть главный класс MainClass.
Есть класс HttpEngine, реализующий http-клиента

class HttpEngine : public QObject {
    ...
public:
    void get(...);
    void post(...);

signals:
    void answer_received(QByteArray, QString);
    ...
};

Есть классы AManager, BManager и CManager, создающиеся в MainClass. Каждый из них должен вызывать методы get/post класса HttpEngine и ожидать ответа, соединившись с его сигналом answer_received.

Варианты:
1. Агрегировать HttpEngine в каждый из классов *Manager и дергать методы каждого уникального экземпляра.
2. Создать в MainClass экземпляр HttpEngine и передавать в конструкторах *Manager классов указатель на него.
В случае варианта №2 каждый раз придется делать disconnect сигнала answer_received, чтобы не вызывались слоты двух других классов, так же ждущих этот сигнал.

Как будет правильней и почему?



Последнее исправление: gektorsir (всего исправлений: 1)

Ответ на: комментарий от pon4ik

Это схема. Троеточия в объявлении класса не смутили?

gektorsir
() автор топика
Ответ на: комментарий от nanoolinux

А не оверхед ли это, если кол-во классов *Manager будет расти?

В потрохах HttpEngine как раз используется QHttpMultiPart.

gektorsir
() автор топика

Какой-то непонятный вопрос. Нужно схемку вообще нарисовать, что откуда и куда. У тебя одна точка входа и одна выхода.

ossa ★★
()

а потом у тебя повятся кукисы и геморой, смотри на servicelocator, хотя если тебе по нраву десткие грабли то можешь сделать HttpEngine синглтоном

Deleted
()

каждый раз придется делать disconnect сигнала answer_received, чтобы не вызывались слоты двух других классов, так же ждущих этот сигнал.

хрень какаято - вызов httpPost возвращает RequestHandler в котором уже будет сигнал о совершении запроса, иначе послав два запрсоа одновременно ты отгребешь приключений

Deleted
()
Ответ на: комментарий от gektorsir

проблема с одним сигналом вызвана не синглтоном а кривым дизайном HttpEngine - посмотри как он сделан например в apache httpcomponents

Deleted
()
Ответ на: комментарий от gektorsir

это не его дизайн примитивне, а его автора ибо в qt есть QNetworkReply (у которго есть сигнал) который возвращет QNetworkAccessManager::get - т.е. все кошерно работает будучи синглтоном

Deleted
()
Ответ на: комментарий от gektorsir

А не оверхед ли это, если кол-во классов *Manager будет расти?

Конечно, ать, оверхед! Ни в коем случае так не делай! Пиши сразу всё на асме с глобальными переменными! Только экономия битов и тактов! Только Харррдкоррр!

nanoolinux ★★★★
()
Ответ на: комментарий от Deleted

Еще раз. HttpEngine реализован через QNetworkAccessManager, который хранит в себе указатель на QNetworkReply, который будет возвращен QNetworkAccessManager::post/get и открыт для чтения.
После этого QNetworkReply сэмитирует сигнал finished, что означает в устройстве (QIODevice) собраны все данные и больше они дописываться не будут. Ответ читается из QNetworkReply и (т.к. их объем мал) отправляются через сигнал answer_received() клиенту, слушающему этот сигнал.

Синглтон, если заюзать синглтон Майерса с C++0x, не будет так уж плох, но проблема в подключенных к сигналу answer_received() слотах.

Пример проблемы:
Шаг 1.
Класс AManager соединяется с сигналом HttpEngine, отсылает
свой post запрос и получает ответ через сигнал answer_received();
Шаг 2.
Класс BManager соединяется с сигналом HttpEngine, отсылает
свой get запрос и получает ответ по сигналу answer_received().
Но этот же сигнал этого же экземпляра HttpEngine уже был подключен к слоту объекта класса AManager.

gektorsir
() автор топика

Не все вводные даны. Однако по представленным данным, я бы сделал агрегатор (по-желанию синглтон). В конструкторе агрегатора создается QNetworkAccessManager. В слоте принимаются все запросы. При приёме средствами QObject::sender() получаем указатель на заказчика, с помощью qobject_cast<>() проверяем его на корректность. Каждый запрос при получении кладём в кеш указатели на заказчика и QNetworkReply. По факту получения ответа от QNetworkAccessManager из кеша дергаем указатель на заказчика и напрямую дергаем метод для передачи ответа. Слоты/сигналы разъеденять не надо, возможна параллельная обработка запросов, никаких лишних экземпляров агрегатора. Просто и аккуратно.

erfea ★★★★★
()
Ответ на: комментарий от gektorsir

Тебе уже несколько раз намекнули, что класс HttpEngine спроектирован отвратно. Или тебя силой заставляют его использовать?

trex6 ★★★★★
()
Ответ на: комментарий от gektorsir

. HttpEngine реализован через QNetworkAccessManager, который хранит в себе указатель на QNetworkReply, который будет возвращен QNetworkAccessManager::post/get и открыт для чтения.

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

Deleted
()
Ответ на: комментарий от Deleted

Да, ты прав. Подход был говно.

Всем спасибо за участие, вопрос закрыт.

gektorsir
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.