Проектирование UI и использование транзакций Опции

[Majestio]

Возник немного комплексный вопрос: как правильно (ну или какие есть приемлемые варианты) организовать пользовательский интерфейс и использовать транзакции для отката в случае отказа пользователя сохранить изменения, в случаях ошибок? Какие ограничения в UI уместны и обоснованы? Вобщем, нужна критика и предложения. Использую Qt и PostgreSQL.

Ситуация такова.

Есть две сущности "Карточки Клиентов" (КК) и "Карточки обслуживания" (КО). Связаны между собой отношением многие-ко-многим. Иными словами - КК может иметь список, состоящий из множества "привязанных" КО. В свою очередь каждая КО может быть как индивидуальной, так и групповой, т.е. включать множество КК. В программе используется SDI.

Примерный сценарий работы:

1. Сотрудник вызывает модальный диалог "Новая КК" (Д1), заполняет основные поля
2. Переключается на вторую вкладку этого диалога "Обслуживание" - там пустая таблица
3.Сотрудник получает возможности:
3.1. выбрать из существующих обслуживаний и включить в нее создаваемого пользователя
3.2. создать новое обслуживание вызвав модальный диалог "Новое Обслуживание" Д2 и включить в него пользователя (автоматом при создании)
4.В диалоге "Новое обслуживание" или "Редактирование Обслуживания" он так же может создать или удалить КК
...
Далее цепочка может быть бесконечной - КК позволяет создавать, редактировать и удалять КО, в свою очередь при редактировании КО - можно создавать, редактировать и удалять КК.

Как собираюсь все это обрабатывать

1. Ограничения по вложенностям вводить не буду;
2. Для обеспечения откатов - перед вызовом первого диалога объявляю транзакцию, и точку отката - если очередной диалог отменен пользователем - откатываюсь до последней точки отката;
3. Глобально веду списки КК и КО, чтобы избежать повторных редактирований или удалений;
4. Веду блокировки записей КК и КО дабы избежать сюрпризов при многопользовательском доступе;
5. Перед вызовом нового диалога, данные по текущему диалогу сбрасываю в БД (иначе привязать к несохраненным данным не получиться, если не строить древовидных структур в памяти, а потом пытаться их обработать);

Как быть с обработкой возможных ошибок при работе с БД в n-ом вложенном диалоге диалоге?
Что будет с открытой транзакцией, если клиент вообще вылетит из сеанса работы с БД по какой-нибудь из причин?

Извините, что вот так сумбурно. Пока не могу все нюансы собрать воедино.

[lanz]

С точки зрения ленивого программиста, очень все сложно, а выгоды неочевидны.
По моему стоит запретить создавать новые карточки из диалога создания новых карточек.

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

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

Сообщение отредактировал lanz - 4.4.2013, 9:03

[Iron Bug]

Как быть с обработкой возможных ошибок при работе с БД в n-ом вложенном диалоге диалоге?

что подразумевается под ошибками?

Что будет с открытой транзакцией, если клиент вообще вылетит из сеанса работы с БД по какой-нибудь из причин?

ничего не будет. она просто откатится, изменения не сохранятся.