Вопрос архитектуры приложения |
Здравствуйте, гость ( Вход | Регистрация )
Вопрос архитектуры приложения |
call_me_Frank |
23.3.2012, 12:21
Сообщение
#1
|
Студент Группа: Участник Сообщений: 73 Регистрация: 20.10.2010 Пользователь №: 2129 Спасибо сказали: 0 раз(а) Репутация: 0 |
Как считаете, господа?
Есть у меня GUI, созданный при помощи QML. Есть "движок" программы. Есть, соответственно, задача реализации обмена данными между ними. Сначала я сделал таким образом, что множество сигналов от интерфейса связывались непосредственно с конкретными функциями движка, ну и в обратную сторону аналогично. Теперь решил переделать это так, что бы было всего 2-3 сигнала в каждую сторону, но теперь каждый сигнал будет нести в себе информацию о том, от кого он, какую операцию представляет, ну и данные. И есть столько же функций приемников, которые занимаются распределением пришедших данных уже по конкретным функциям. Такая вот прослойка. В итоге получаем уменьшение количества, скажем так, каналов связи между GUI и движком, и, возможно, некоторую универсальность, на будущее, при добавлении новых функций с той или другой стороны. Пишу это, потому что имеются некоторые сомнения в сердце , насколько оправдан такой подход? Как считаете, господа?) |
|
|
RazrFalcon |
23.3.2012, 14:14
Сообщение
#2
|
Zombie Mod Группа: Участник Сообщений: 1654 Регистрация: 24.5.2010 Из: Харьков Пользователь №: 1752 Спасибо сказали: 64 раз(а) Репутация: 212 |
Если сигналов очень много можно заюзать QSignalMapper и подобные.
А так - предпочтение каждого. Я вот не люблю в сигнале передавать 100500 параметров. Разве что их в структуру/класс загнать, и уже это передавать. |
|
|
call_me_Frank |
23.3.2012, 16:03
Сообщение
#3
|
Студент Группа: Участник Сообщений: 73 Регистрация: 20.10.2010 Пользователь №: 2129 Спасибо сказали: 0 раз(а) Репутация: 0 |
Если сигналов очень много можно заюзать QSignalMapper и подобные. А так - предпочтение каждого. Я вот не люблю в сигнале передавать 100500 параметров. Разве что их в структуру/класс загнать, и уже это передавать. отлично, спасибо! щас почитаю нет, всё-таки, QSignalMapper - это не тот вариант... вот что еще хотел узнать (пока с этим сталкиваться не приходилось, в поиске с ходу тоже не нашел), можно ли каким-то образом вызывать метод объекта по его "текстовому" названию, то есть вызывать не как obj.method1(params), а как-нибудь вроде obj.methods["method1"](params); ? |
|
|
MoPDoBoPoT |
23.3.2012, 23:08
Сообщение
#4
|
Участник Группа: Участник Сообщений: 172 Регистрация: 7.5.2009 Из: Москва Пользователь №: 738 Спасибо сказали: 44 раз(а) Репутация: 9 |
|
|
|
Гость_Гость_* |
26.3.2012, 20:05
Сообщение
#5
|
Гости |
Можно, например, в QML код передавать некий высокоуровневый обьект(ы), который представляет на нужном уровне детализации весь серверный код и производить общение уже через него . На проекте на котором я работаю именно такая архитектура и используется, и вполне успешно.
Например если пишешь некий плеер, то в первом приближении это выглядело бы примерно так:
Притом обьект может быть один а интерфейсов сколько угодно, правда тогда скорей всего придется отказаться от плюшек QObject'a или делать какую нибудь унифицированною систему эвентов построеную на сигналах. Хотя Qt'ишная система плагинов вроде позволяет такой подход без отказа от QObject, попробуй почитать про всякие Q_DECLARE_INTERFACE, Q_INVOKABLE и т.д. |
|
|
Текстовая версия | Сейчас: 22.11.2024, 10:27 |