Вопрос сохранения данных.

[nata267]

Допустим я проектирую программу-редактор чегото там. У меня в интерфейсе программы есть окошко типа QDockWidget+QTreeView, где пользователь будет формировать древовидную структуру чегото там с помощью кнопок "Добавить узел такого-то типа", "Удалить", "Переименовать", "Переместить" и т.д.  Когда мы щелкаем на созданный узел в другое окошко загружается содержимое этого узла. Допустим это форма с элементами типа: текстовое поле, картинка, видео, аудио файл. Эти элементы можно двигать на форме, менять размер. БД, где все это хранится после сохранения пользователем путь будет MYSQL.

Вопрос заключается в том. Как организовать хранение всех изменений и сохранения общего изменившегося состояния в БД по кнопке главного меню "Сохранить"? Если бы можно было сохранять только изменения формы это была бы простая задача. Но как быть с древовидной структурой? Я дала упрощенное описание программы. На самом деле она намного сложнее, там куча окошек с различными данными которые изменяет пользователь. Все изменения фиксируются в базе где куча взаимосвязанных таблиц. Как делать общее сохранение данных по кнопке сохранить?? Какие есть варианты решения данной задачи?? И еще вопрос. Является ли это архитектурной задачей?? И стоит ли её рассматриваить и выделять отдельную ветку для решения архитектурных задач?

[Bepec]

Кхм. А сохранить всю базу, религия не позволяет?

[alexis031182]

Кхм. А сохранить всю базу, религия не позволяет?

undo/redo хранят на время одной сессии работы приложения. В БД держать это ни к чему.

[alexis031182]

Как делать общее сохранение данных по кнопке сохранить??

Как обычно. Пройтись по списку виджетов и сохранить их текущее состояние в БД.

Какие есть варианты решения данной задачи??

Я бы сделал через медиатор + классы, хранящие состояние виджетов. Только медиатор должен быть Медиатором в данном случае, а не простым контейнером перекрёстных ссылок. Медиатор сам реализует логику, и не должен использоваться в роли пассивного участника событий.

И еще вопрос. Является ли это архитектурной задачей?? И стоит ли её рассматриваить и выделять отдельную ветку для решения архитектурных задач?

Страшное слово. Не загоняйте себя в рамки. Задача как задача, не более и не менее архитектурна, нежели другие.

[nata267]

Как делать общее сохранение данных по кнопке сохранить??

Как обычно. Пройтись по списку виджетов и сохранить их текущее состояние в БД.

Это очень хорошо, но тогда есть вопросы. Во-первых, в базе храняться несколько проектов. Их пользователь открывает по кнопке допустим "Открыть проект". В этом случае предыдущий проект должен быть сохранен и закрыт. То есть вы предлагаете при сохранении стереть в базе данных всю информация касающуюся этого проекта и занести целиком новую во все таблицы или как?? Там куча взаимосвязанных таблиц. и куча данных по проекту. Изменение проекта за один сеанс работы с ним может быть как незначительным, так и кардинально меняющим вообще всю структуру проекта. И в том и в том случае придется сгененрировать и запустить кучу запросов? Это разве рационально?? Или вы имеете ввиду помечать элементы бд статусами deleted, inserted, modified. Поясните пожалуйста??

[nata267]

Какие есть варианты решения данной задачи??

Я бы сделал через медиатор + классы, хранящие состояние виджетов. Только медиатор должен быть Медиатором в данном случае, а не простым контейнером перекрёстных ссылок. Медиатор сам реализует логику, и не должен использоваться в роли пассивного участника событий.

Если я не ошибаюсь,то вы предлагаете наследовать все элементы, хранящиеся в бд от одного класса например DBObject. и медиатор, хранящий ссылки на все эти объекты, медиатор проходит по объектам и смотрит их состояние (inserted, modified, deleted) и в зависимости от этого выполняется запрос к базе??? Правда в этом случае это уже не медиатор, а итератор)) Но там очень много иерархических и взаимосвязанных по id структур( Id генерируются при вставке в бд автоматически).  Как быть с их удалением, вставкой?

[nata267]

И еще вопрос. Является ли это архитектурной задачей?? И стоит ли её рассматриваить и выделять отдельную ветку для решения архитектурных задач?

Страшное слово. Не загоняйте себя в рамки. Задача как задача, не более и не менее архитектурна, нежели другие.

К какому же существующему разделу на этом форуме  можно отнести эту тему?

[nata267]

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

Почему он не должен быть простым контейнером перекрестных ссылок? И как он должен реализовывать логику? И почему медиатор, а не итератор?? Вообще не могу себе представить ваш медиатор. Что он вообще делает??

[Bepec]

http://ru.wikipedia.org/wiki/Медиатор

[nata267]

http://ru.wikipedia.org/wiki/Медиатор

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

[alexis031182]

Это очень хорошо, но тогда есть вопросы. Во-первых, в базе храняться несколько проектов. Их пользователь открывает по кнопке допустим "Открыть проект". В этом случае предыдущий проект должен быть сохранен и закрыт. То есть вы предлагаете при сохранении стереть в базе данных всю информация касающуюся этого проекта и занести целиком новую во все таблицы или как?? Там куча взаимосвязанных таблиц. и куча данных по проекту. Изменение проекта за один сеанс работы с ним может быть как незначительным, так и кардинально меняющим вообще всю структуру проекта. И в том и в том случае придется сгененрировать и запустить кучу запросов? Это разве рационально?? Или вы имеете ввиду помечать элементы бд статусами deleted, inserted, modified. Поясните пожалуйста??

А почему нерационально? Только конечно в БД следует вносить изменения только в те записи, виджеты которых реально изменились. А за фактом изменения каждого конкретного виджета должен следить медиатор.

[nata267]

Это очень хорошо, но тогда есть вопросы. Во-первых, в базе храняться несколько проектов. Их пользователь открывает по кнопке допустим "Открыть проект". В этом случае предыдущий проект должен быть сохранен и закрыт. То есть вы предлагаете при сохранении стереть в базе данных всю информация касающуюся этого проекта и занести целиком новую во все таблицы или как?? Там куча взаимосвязанных таблиц. и куча данных по проекту. Изменение проекта за один сеанс работы с ним может быть как незначительным, так и кардинально меняющим вообще всю структуру проекта. И в том и в том случае придется сгененрировать и запустить кучу запросов? Это разве рационально?? Или вы имеете ввиду помечать элементы бд статусами deleted, inserted, modified. Поясните пожалуйста??

А почему нерационально? Только конечно в БД следует вносить изменения только в те записи, виджеты которых реально изменились. А за фактом изменения каждого конкретного виджета должен следить медиатор.

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

[alexis031182]

Если я не ошибаюсь,то вы предлагаете наследовать все элементы, хранящиеся в бд от одного класса например DBObject.

Нет. Виджеты как были так и пусть будут. Не надо никаких их наследований.

и медиатор, хранящий ссылки на все эти объекты

Так точно.

, медиатор проходит по объектам и смотрит их состояние (inserted, modified, deleted) и в зависимости от этого выполняется запрос к базе???

Нет. Каждый виджет должен сам информировать медиатор о своих изменениях.

Правда в этом случае это уже не медиатор, а итератор)) Но там очень много иерархических и взаимосвязанных по id структур( Id генерируются при вставке в бд автоматически).  Как быть с их удалением, вставкой?

Ну вот смотрите. У Вас имеется набор виджетов. Каждый виджет при изменении отправляет в медиатор событие, что изменилось: НАИМЕНОВАНИЕ_ПАРАМЕТРА, ЗНАЧЕНИЕ_ПАРАМЕТРА.

Медиатор, прекрасно представляя, собственно, от кого пришёл очередной посыл, создаёт объект класса состояния виджета для истории (стек), куда и заносит эту информацию. Соответственно, если хоть одно событие по какому-то виджету подобного рода медиатор получил, значит медиатор ставит этому виджету флаг - ИЗМЕНЁННЫЙ.

Далее, думаю, ясно.

[alexis031182]

К какому же существующему разделу на этом форуме  можно отнести эту тему?

Это конечно не в кладовой. "Общие вопросы" наверное единственный вариант.

[alexis031182]

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

Медиатор хранит не только указатели на объекты виджетов, но и указатели на объекты классов состояний виджетов, которых, в случае необходимости, может быть своя, параллельная виджетам иерархия.