Единица работы. Каков наилучший подход к временному хранилищу объектов на веб-ферме?

Question

Мне нужно спроектировать и реализовать нечто похожее на то, что Мартин Фаулер называет шаблоном «Единица работы».Я слышал, как другие называют это шаблоном «корзина для покупок», но я не уверен, что потребности одинаковы.

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

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

Я вижу в этом несколько недостатков.

• Это вызывает возмущения в индексах.
• Нам все еще нужно придумать что-то, чтобы удовлетворить ограничения уникальности для столбцов, которые их имеют.
• Нам придется изменить множество существующих SQL и код, генерирующий SQL, чтобы добавить еще один предикат ко многим предложениям WHERE.
• Изменить первичные ключи в Oracle можно, но это сложная задача.

б) Создайте таблицы переходных процессов для объектов и назначений, которые должны иметь возможность участвовать в этих обратных транзакциях.Когда пользователь нажимает «Отправить», мы генерируем настоящие записи и удаляем старые.

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

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

Кто-нибудь решил эту проблему по-другому?

Заранее спасибо за вашу помощь.

Answer 1

Я не понимаю, почему эти объекты необходимо создавать в базе данных до того, как транзакция будет зафиксирована, поэтому вы можете уточнить это у своей команды пользовательского интерфейса, прежде чем приступать к решению.Вы можете обнаружить, что все, что им нужно, — это прочитать информацию, ранее сохраненную пользователем на другой странице.

Итак, предполагая, что объекты не нужно хранить в базе данных перед фиксацией, я предлагаю вам план C:

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