Система сообщений(философия)

← →
Хохол (2008-07-08 03:14) [0]

Проблема такая:

Есть некие объекты(простых - список и сложных структур типа дерево и сеть) отображаемые в базу данных (ORM).

Данные объекты могут быть извлечены во множественном числе (одна и та же сущность в виде нескольких объектных воплощений, архитектура такая), но при изменении их необходимо как-то уведомить остальные объекты той же сущности синхронизироваться с базой данных.

Пока спроектировал решение с провайдером сообщений, слушателями регистрируемыми между провадером и данными объектами сущностей и отсылкой сообщений через провайдера всем заинтересованным слушателям об изменении конкретного объекта.

Есть ли другая более простая концепция - поддержания актуальности данных для множественных объектных отображений одной сущности (в примитивном варианте записи в таблице БД).

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

← →
Юрий Зотов © (2008-07-08 03:34) [1]

> решение с провайдером сообщений, слушателями регистрируемыми между
> провадером и данными объектами сущностей и отсылкой сообщений через
> провайдера всем заинтересованным слушателям об изменении
> конкретного объекта.

Нормальное решение.

> перечитывать данные из бд по таймеру

Ненормальное решение.

← →
iZEN (2008-07-08 05:11) [2]

Образец MVC == жёсткое разделение данных на Модель, Контроллёры и Представления.

Общая шина солбщений == транспорт.

← →
ketmar © (2008-07-08 11:10) [3]

эх, батенька, всё украдено до нас. и думать особо не надо было, MVC давно изобрели и активно используют…

---
All Your Base Are Belong to Us

← →
ketmar © (2008-07-08 11:11) [4]

>[0] Хохол (2008-07-08 03:14:00)
то есть, проще говоря, ты изобрёл именно обычное решение в таких случаях. на таймер не смотри, пиши модели. кода будет побольше в начале, но потом хоть работать будет, в отличие от таймеров.

---
All Your Base Are Belong to Us

← →
Украинец (2008-07-08 14:54) [5]

> ketmar © (08.07.08 11:11) [4]
>
> >[0] Хохол (2008-07-08 03:14:00)
> то есть, проще говоря, ты изобрёл именно обычное решение
> в таких случаях. на таймер не смотри, пиши модели. кода
> будет побольше в начале, но потом хоть работать будет, в
> отличие от таймеров.

Я его не изобрёл, я его содрал (с некоторыми изменениями). Вот только решил спросит измышление ли это или рабочий вариант.

← →
ketmar © (2008-07-08 15:39) [6]

>[5] Украинец (2008-07-08 14:54:00)
>Я его не изобрёл, я его содрал
это несущественно. всё уже придумано до нас.

---
Understanding is not required. Only obedience.

Что меня бесит в паттерне Observer, который ты и пименил, так это отладка. Из-за этой автоматической рассылки сообщений, отлаживать противно или невозможно, и лог здоровый.

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

И еще, я не понял кое что в твоём решении.

0. Есть БД.
1. Есть объекты предм. области, которые получены из БД.
2. "спроектировал решение с провайдером сообщений" - имеем медиатор (кстати чем названия ближе к GoF паттернам, тем быстрее посторонние врубаются в суть).
Тут все ясно.

"слушателями регистрируемыми между провадером и данными объектами сущностей"
Выходит слушатели - это не объекты предм области. А кто это такие? Что они делают?

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

← →
Украинец (2008-07-08 17:47) [8]

> Kolan © (08.07.08 17:17) [7]

Архитектуру изменить никак - есть некоторые "документы" изменяемые в нескольких редакторах (причём один "документ" может редактироваться одновременно редакторами). При этом происходит его синхронизация с БД (блокировки на редактирование невозможны по ТЗ заказчика, один документ может просматриваться или редактироваться множеством редакторов), при этом нужно уведомить другие "документы"/редакторы что произошло изменение.

Редактирование "документов" происходит редко, а чтение часто множеством субъектов.

Слушатели - специальный объект который регистрируется у подписчика и при получении сообщения вызывает свой делегат(адрес функции), чтобы не пришлось добавлять методы слушателей для объектов БД.

В общем это частный случай паттерна Наблюдатель - (Издатель-Подписчик).

> В общем это частный случай паттерна Наблюдатель - (Издатель-
> Подписчик).

Я же и говорю Observer. Да не, нормальное решение. Особенно другого тут и не придумешь имхо.

Только тут у тебя более высокоуровневая задача. Программы должны общаться.

Я бы сделал сервер, который бы:
а. отдавал документы
б. рассылал уведомление

То есть, А и Б, допустим открыли документы. Сервер это запомнил, если А изменил док. и сохранил его, то Б получит уведомление.

Имхо это уже есть в серверах БД. Например MS SQL кажется такое может, но где искать незнаю. И еще можно поизучать системы контроля версий (SVN). По сути вы её и делаете.

Система сообщений(философия) Найти похожие ветки