Единица работы - Каков наилучший подход к временному хранению объектов в веб-ферме? - PullRequest
2 голосов
/ 05 октября 2009

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

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

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

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

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

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

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

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

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

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

1 Ответ

1 голос
/ 05 октября 2009

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

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

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

...