Задача дизайна - прокинуть детали низкоуровневой реализации на более высокий уровень и вернуть обратно

@Kastaneda · Регистрация: 12.12.2009

Студворк — интернет-сервис помощи студентам

Привет!

Задача возникла на работе. Мозговым штурмом было предложено 100500 реализаций, одно из них выбрали, но хотелось бы посмотреть на альтернативные варианты

Итак - есть RPC канал, который реагирует на события AMQP сервера (используется событийная модель). Из RPC канала нужно асинхронно ответить на сообщение, для этого AMQP нужны данные, о которых знает только AMQP. Т.е. эти данные нужно прокинуть из AMQP в RPC, и RPC потом должен эти данные вернуть. Чтоб все было кошерно нужно:
1. Чтобы RPC не знал об AMQP (транспорт должен быть заменяемым)
2. Не нужно заставлять пользователя (т.е. RPC) что-то куда-то прокидывать

Чтоб было понятней (очень упращенный вариант)

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// AMQP
void AmqpServer::mainLoop()
{
    // что-то делаем, в итоге получаем сообщение
   // при этом есть некий ID, который нужно знать при отправке ответа
   
    _messageHandler->onMessageReceived(message/*, также нужно как-то прокинуть упомянутый ID*/);
}
 
void AmqpServer::sendResponse (std::string response, /* и еще нужно знать упомянутый выше ID*/)
{
    // отправляем сообщение, используя ID
}
 
// RPC
void RpcChannel::onMessageReceived (std::string message/*, нужен еще ID*/)
{
    // обработали сообщение, сформировали ответ
 
    _responseHandler->sendResponse(response/*, плюс нужно вернуть ID*/);
}

Вариант с кешированием IDшников на стороне сервера сразу отметаем по ряду причин. Есть предложения?

@vxg · 22.11.2016, 13:57

Kastaneda, для тех кто не знает что такое AMQP и RPC можно сформулировать или технические особенности этих заклинаний здесь принципиальны? если да, то этого почему-то не видно по примеру

@Kastaneda · 22.11.2016, 14:03 **[ТС]**

Сообщение от vxg

Kastaneda, для тех кто не знает что такое AMQP и RPC можно сформулировать или технические особенности этих заклинаний здесь принципиальны? если да, то этого почему-то не видно по примеру

Технические особенности не принципиальны. Попробую объяснить - AMQP это протокол передачи данных (по сети), используется в качестве транспорта. RPC - это тоже протокол, но более высокого уровня, ему без разницы через какой транспорт к нему пришло сообщение, хоть через HTTP.

Если проводить аналогию, то можно представить, что вместо AMQP имеется ввиду TCP, а вместо RPC - HTTP. И теперь представим, что для отправки HTTP ответа уровень HTTP должен знать о каких-то деталях реализации TCP, понятно, что это не правильно. И у нас получается, что уровень RPC должен знать об AMQP.

@vxg · 22.11.2016, 14:10

Kastaneda
то есть имеем объект 1-го уровня через который проходят данные попадающее объекту 2-го уровня и объекту 2-го уровня нужно знать об этих данных нечто доступное лишь объекту 1-го уровня?

@Kastaneda · 22.11.2016, 14:14 **[ТС]**

vxg, да и задача в том, чтобы оградить объект 2-го уровня от этих знаний, т.к. чисто теоретически тип объекта 1-го уровня может быть другим и иметь другую реализацию.

@vxg · 22.11.2016, 14:19

Kastaneda, если объект 1-го уровня может вызвать обработчик объекта 2-го уровня во время приема данных (вместо вызова обработчика неким стандартным механизмом) и передать в этом обработчике нужные данные наверное это самое естественное решение кроме кэша

@Kastaneda · 22.11.2016, 14:24 **[ТС]**

Сообщение от vxg

если объект 1-го уровня может вызвать обработчик объекта 2-го уровня во время приема данных (вместо вызова обработчика неким стандартным механизмом) и передать в этом обработчике нужные данные наверное это самое естественное решение кроме кэша

Оно выглядит просто, но оно не правильное. Завтра мы меняем AMQP на тот же HTTP и нам данные AMQP не нужны - придется переписываться код. Или мы хотим использовать 2 вида транспорта одновременно - тогда вообще получится несовместимость.

@vxg · 22.11.2016, 15:13

Kastaneda, если вы владеете структурой данных прикрепляйте нужную информацию нижнего уровня в экстру

@Kastaneda · 22.11.2016, 16:37 **[ТС]**

vxg, нужно передать 2 поля (в примере в 1-ом посте показал одно просто для примера), но в идеале кол-во полей должно быть любым, поэтому поле extra будет непонятно какого типа (не void* же делать

).

Сообщение от vxg

если вы владеете структурой

можно варьировать как угодно, пока есть возможность менять интерфейсы/сигнатуры.

@vxg · 22.11.2016, 16:45

Kastaneda, ну так сделать это поле std::list<VARIANT>

Добавлено через 38 секунд
или лучше std::map<std::string, VARIANT> что бы уж с именами)

Добавлено через 2 минуты
хотя с именами не айс, нужны цифровые идентификаторы)

Добавлено через 25 секунд
что бы проверились в CT и можно было спать спокойно

@Kastaneda · 23.11.2016, 07:38 **[ТС]**

Сообщение от vxg

или лучше std::map<std::string, VARIANT> что бы уж с именами)

Была такая идея, но это решение попахивает)

@vxg · 23.11.2016, 09:02

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

@Kastaneda · 23.11.2016, 09:27 **[ТС]**

Сообщение от vxg

идеал - это когда вы знаете поля которые вам нужны - тогда экстра это просто структура с вашими полями

Тогда верхний уровень будет знать о деталях реализации нижнего. И, если разработчик наркоман, то он может их даже переписать эти данные на верхнем уровне. Этого хочется избежать.

@vxg · 23.11.2016, 09:33

Kastaneda,
1 верхний уровень хочет знать что то что не дает ему стандартная реализация. для этого мы делаем экстру. если экстра различная для разных реализаций нижнего уровня (что само по себе странно ибо как тогда работает верхний уровень если он не знает какие доп данные ему нужны), то можно на верхнем уровне различать экстры по типам. например экстра TCP или экстра UDP и соответственно по разному с ними работать.
2 если разработчик неадекват, то он может просто не использовать ваши данные. если есть желание защитить сами данные из-за того что они используются еще где-то в цепочке можно возвращать их не в структуре, а в объекте с доступом к полям через get функции.

@Kastaneda · 23.11.2016, 09:51 **[ТС]**

Сообщение от vxg

верхний уровень хочет знать что то что не дает ему стандартная реализация.

В том то и дело, что верхнему уровню это не надо. Теоретически можно на нижнем уровне все кешировать и на верх ничего не отдавать, но кешировать нельзя по ряду причин. Поэтому приходится отдавать это на верх.

@vxg · 23.11.2016, 12:43

Сообщение от Kastaneda

В том то и дело, что верхнему уровню это не надо

это даже проще. тогда нижний уровень что ему надо положит в экстру и что надо из нее возьмет

IGPIGP · 23.11.2016, 12:58

Сообщение от Kastaneda

Итак - есть RPC канал, который реагирует на события AMQP сервера (используется событийная модель). Из RPC канала нужно асинхронно ответить на сообщение, для этого AMQP нужны данные, о которых знает только AMQP. Т.е. эти данные нужно прокинуть из AMQP в RPC, и RPC потом должен эти данные вернуть.

Kastaneda, как я понимаю (из сказанного):
-RPC не знает и не изменяет указанные данные, а пропускает их транзитом
-AMQP использует указанные данные как id для идентификации в момент получения ответа собственного состояния на момент отправки сообщения на которое данный ответ получен.
Верно?

@Kastaneda · 23.11.2016, 13:15 **[ТС]**

IGPIGP, да, все верно. Грубо говоря AMQP при отправке ответа добавляет в ответ данные, по которым можно понять на какой именно запрос этот ответ. И это детали реализации AMQP.

vxg, получается "кишками наружу")

@vxg · 23.11.2016, 13:24

Сообщение от IGPIGP

использует указанные данные как id для идентификации в момент получения ответа собственного состояния на момент отправки сообщения на которое данный ответ получен

ооо... *откидывается на спинку кресла и начинает думать*

IGPIGP · 23.11.2016, 13:37

Сообщение от vxg

откидывается на спинку кресла и начинает думать

Андрей Ефимыч?

Сообщение от Kastaneda

да, все верно

И как я понимаю, кешировать нельзя из-за того что не на все сообщения могут быть ответы.

Тогда совет vxg, это выход.
Я бы добавил, что стоит проанализировать имеющийся пакет в прямом сообщении. На предмет есть ли там место для "комментария" в виде id.
Важно ещё проанализировать количество различных состояний дифференцируемых на предмет обработки ответа, чтобы понять какой длины поле следует выбрать.

Новые блоги и статьи Все статьи Все блоги /
Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы, точка. Programma_Boinc 23.12.2025 Рецензия / Мнение/ Перевод Ниже машинный перевод статьи The Thinkpad X220 Tablet is the best budget school laptop period . Thinkpad X220 Tablet — это лучший бюджетный ноутбук для учёбы,. . .	PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .
От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .

@vxg Модератор 3406 / 2177 / 354 Регистрация: 13.01.2012 Сообщений: 8,444
	22.11.2016, 13:57
	Kastaneda, для тех кто не знает что такое AMQP и RPC можно сформулировать или технические особенности этих заклинаний здесь принципиальны? если да, то этого почему-то не видно по примеру 1

@vxg Модератор 3406 / 2177 / 354 Регистрация: 13.01.2012 Сообщений: 8,444
	22.11.2016, 14:10
	Kastaneda то есть имеем объект 1-го уровня через который проходят данные попадающее объекту 2-го уровня и объекту 2-го уровня нужно знать об этих данных нечто доступное лишь объекту 1-го уровня? 0

@Kastaneda 5232 / 3205 / 362 Регистрация: 12.12.2009 Сообщений: 8,143 Записей в блоге: 2
	22.11.2016, 14:14 [ТС]
	vxg, да и задача в том, чтобы оградить объект 2-го уровня от этих знаний, т.к. чисто теоретически тип объекта 1-го уровня может быть другим и иметь другую реализацию. 0

@vxg Модератор 3406 / 2177 / 354 Регистрация: 13.01.2012 Сообщений: 8,444
	22.11.2016, 14:19
	Kastaneda, если объект 1-го уровня может вызвать обработчик объекта 2-го уровня во время приема данных (вместо вызова обработчика неким стандартным механизмом) и передать в этом обработчике нужные данные наверное это самое естественное решение кроме кэша 0

@vxg Модератор 3406 / 2177 / 354 Регистрация: 13.01.2012 Сообщений: 8,444
	22.11.2016, 15:13
	Kastaneda, если вы владеете структурой данных прикрепляйте нужную информацию нижнего уровня в экстру 0

@vxg Модератор 3406 / 2177 / 354 Регистрация: 13.01.2012 Сообщений: 8,444
	22.11.2016, 16:45
	Kastaneda, ну так сделать это поле std::list<VARIANT> Добавлено через 38 секунд или лучше std::map<std::string, VARIANT> что бы уж с именами) Добавлено через 2 минуты хотя с именами не айс, нужны цифровые идентификаторы) Добавлено через 25 секунд что бы проверились в CT и можно было спать спокойно 0

@vxg Модератор 3406 / 2177 / 354 Регистрация: 13.01.2012 Сообщений: 8,444
	23.11.2016, 09:02
	Kastaneda, идеал - это когда вы знаете поля которые вам нужны - тогда экстра это просто структура с вашими полями. Если поля неизвестны и могут меняться то иного способа кроме абстрактного списка логически вроде нет 0

@vxg Модератор 3406 / 2177 / 354 Регистрация: 13.01.2012 Сообщений: 8,444
	23.11.2016, 09:33
	Kastaneda, 1 верхний уровень хочет знать что то что не дает ему стандартная реализация. для этого мы делаем экстру. если экстра различная для разных реализаций нижнего уровня (что само по себе странно ибо как тогда работает верхний уровень если он не знает какие доп данные ему нужны), то можно на верхнем уровне различать экстры по типам. например экстра TCP или экстра UDP и соответственно по разному с ними работать. 2 если разработчик неадекват, то он может просто не использовать ваши данные. если есть желание защитить сами данные из-за того что они используются еще где-то в цепочке можно возвращать их не в структуре, а в объекте с доступом к полям через get функции. 0

@Kastaneda 5232 / 3205 / 362 Регистрация: 12.12.2009 Сообщений: 8,143 Записей в блоге: 2
	23.11.2016, 13:15 [ТС]
	IGPIGP, да, все верно. Грубо говоря AMQP при отправке ответа добавляет в ответ данные, по которым можно понять на какой именно запрос этот ответ. И это детали реализации AMQP. vxg, получается "кишками наружу") 0