Как мне написать обработку очереди сообщений объектно-ориентированным способом?

Question

Если бы вам пришлось писать код, который принимает сообщения из очереди сообщений и обновляет таблицу в базе данных, как бы вы хорошо ее структурировали? Как бы вы это структурировали? Сообщения представляют собой данные XML, по одному узлу на строку в таблице. Строки в таблице могут быть обновлены, удалены или вставлены.

Answer 1

Не думаю, что вы предоставили достаточно информации для хорошего ответа. Как выглядят сообщения? Они различаются по содержанию / типу, или они все просто "сообщения"? Они взаимодействуют друг с другом или это просто преобразование формата данных? Одним из ключей к разработке ОО является осознание того, что игра «найди существительные-н-глаголы» (а это столько, сколько ты описал) редко приводит к лучшему решению. Это, конечно, не будет худшим, но в итоге вы получите агрегацию данных и кучу процедурного кода.

Процедурный код неплох, хотя. Почему это должно быть ОО? Требует ли сама проблема полиморфизма и сокрытия данных? Есть ли какое-то сложное поведение, которое вы пытаетесь смоделировать? Нет ничего постыдного в том, чтобы использовать решение без OO, когда проблема проста.

Answer 2

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

С помощью основанных на конфигурации сред персистентности вы можете просто настроить постоянство для этих классов напрямую.

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

Answer 3

Лучший способ создания ОО-кода при обмене сообщениями или работе с любым видом промежуточного ПО - это скрыть API промежуточного ПО от вашего кода и просто работать с бизнес-логикой.

например. см. эти примеры

• POJO Потребляет , что в значительной степени соответствует описанному вами сценарию использования и
• POJO Создание , если вам когда-либо понадобится отправить сообщения в очередь сообщений.

Тогда вам просто нужно определить, как будут выглядеть объекты передачи данных ; как вы хотите кодировать вещи по проводам в XML / JSON / что угодно.

Отличительной особенностью этого подхода является то, что ваш код теперь полностью независим от промежуточного программного обеспечения - вы можете поменять очередь сообщений и использовать базу данных или JavaSpace или SEDA в памяти или файлы или любой другой протокол связи или API промежуточного ПО .