Форум: "Прочее";
Текущий архив: 2008.08.31;
Скачать: [xml.tar.bz2];
ВнизСистема сообщений(философия) Найти похожие ветки
← →
Хохол (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.
← →
Kolan © (2008-07-08 17:17) [7]Что меня бесит в паттерне Observer, который ты и пименил, так это отладка. Из-за этой автоматической рассылки сообщений, отлаживать противно или невозможно, и лог здоровый.
Мой личный опыт говорит о том, что надо хорошенько подумать как упростить твою архитектуру. Чтобы это сделать, надо конкретнее описать задачу.
И еще, я не понял кое что в твоём решении.
0. Есть БД.
1. Есть объекты предм. области, которые получены из БД.
2. "спроектировал решение с провайдером сообщений" - имеем медиатор (кстати чем названия ближе к GoF паттернам, тем быстрее посторонние врубаются в суть).
Тут все ясно.
"слушателями регистрируемыми между провадером и данными объектами сущностей"
Выходит слушатели - это не объекты предм области. А кто это такие? Что они делают?
-------
Обсалютно другой правильной концепции, имхо, нет. Но вот настроить эту под конкретную задачу, имхо, можно и нужно.
← →
Украинец (2008-07-08 17:47) [8]
> Kolan © (08.07.08 17:17) [7]
Архитектуру изменить никак - есть некоторые "документы" изменяемые в нескольких редакторах (причём один "документ" может редактироваться одновременно редакторами). При этом происходит его синхронизация с БД (блокировки на редактирование невозможны по ТЗ заказчика, один документ может просматриваться или редактироваться множеством редакторов), при этом нужно уведомить другие "документы"/редакторы что произошло изменение.
Редактирование "документов" происходит редко, а чтение часто множеством субъектов.
Слушатели - специальный объект который регистрируется у подписчика и при получении сообщения вызывает свой делегат(адрес функции), чтобы не пришлось добавлять методы слушателей для объектов БД.
В общем это частный случай паттерна Наблюдатель - (Издатель-Подписчик).
← →
Kolan © (2008-07-10 12:59) [9]> В общем это частный случай паттерна Наблюдатель - (Издатель-
> Подписчик).
Я же и говорю Observer. Да не, нормальное решение. Особенно другого тут и не придумешь имхо.
Только тут у тебя более высокоуровневая задача. Программы должны общаться.
Я бы сделал сервер, который бы:
а. отдавал документы
б. рассылал уведомление
То есть, А и Б, допустим открыли документы. Сервер это запомнил, если А изменил док. и сохранил его, то Б получит уведомление.
Имхо это уже есть в серверах БД. Например MS SQL кажется такое может, но где искать незнаю. И еще можно поизучать системы контроля версий (SVN). По сути вы её и делаете.
Страницы: 1 вся ветка
Форум: "Прочее";
Текущий архив: 2008.08.31;
Скачать: [xml.tar.bz2];
Память: 0.47 MB
Время: 0.013 c