Товарищи, подскажите, как правильно построить архитектуру. Есть модели, в которых

Question

Товарищи, подскажите, как правильно построить архитектуру. Есть модели, в которых

хранятся данные для вьюх. Модель загружает данные с restapi сервера. При запуске приложения и ввода логина и пароля, модель запрашивает у api access (2 токена). Другие модели запрашивают данные и прикладывают к запросу один из полученных токенов. Как мне правильно построить архитектуру? Сделать одну сущность типа clientapi, и из модели отправлять ей сигналы со своим *qnetworkreply или у каждой модели своя сущность в виде clientapi. С одной стороны, каждой сущностью клиентапи легко изменять на месте, но как тут грамотно без лапши отдать каждой созданной сущности валидные токены? Этот вопрос не возникает на примере использования одной общей сущности clientapi. Но тут у меня получается лапша в виде сигналов (модель - appmanager - clientapi), сигнатура сигнала может содержать указатель на qnetworkreply каждой из модели. И в модели уже по сигналу reply::finished парсить ответ. Но тут есть свои минусы: при смене какой либо структуры или элемента ответа (json), к примеру, кода ошибки - мне придется в каждой модели менять код. Сделать интерфейс ? Подскажите как лучше поступить

#qt #russian #software

0

10.07.2019

1 ответов

22 просмотра

FPOHTMEH · Accepted Answer

Конечно зависит от ситуации, и твое описание не даёт полную картину. Попробуй отделить "сетевые классы" от моделей, которые используются в вьюхах. Для каждого вида web-запроса создай отдельный класс, например: TokenRequest, UserListRequest, AuthorizationRequest - так часто делаю. А связывай модель и результат реквеста уже в ином месте, например: userModel->setUsers(userListRequest->getUsers())

52 похожих чатов

Товарищи, подскажите, как правильно построить архитектуру. Есть модели, в которых

1 ответов

Похожие вопросы