График объекта / вопрос о постоянстве

Question

В настоящее время я работаю с онлайн-приложением, для завершения которого требуется несколько экранов / шагов. Домен приложения моделируется с использованием графа объектов. Постоянство в базе данных и из нее выполняется с помощью пакета ORM.

По мере продвижения по экранам я строю граф объектов. Между экранами я сериализую / десериализирую граф объекта в текущую сессию. К тому времени, когда я достигаю последнего экрана, граф объектов завершен, и я сохраняю его в своей базе данных.

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

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

Надеюсь, мой вопрос сформулирован достаточно четко. Это кажется довольно распространенным явлением.

EDIT:

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

Answer 1

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

Вы также можете проверить Spring Webflow - он имеет дело с такого рода сценарием в состоянии потока (которое также сохраняется в сеансе).

Answer 2

Я бы лично пошел с опцией

заполнение / сериализация / десериализация отдельных объектов через экраны, а затем построение графа окончательных объектов непосредственно перед сохранением в базе данных

по 2 причинам. Во-первых, если вы строите свое приложение с использованием более мелких модулей и в конце собираете объектный граф, это должно упростить модульное тестирование и позволит повторно использовать потоки деталей / экранов.

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

При публикации моего ответа я предположил, что вы выбрали правильную технологическую модель, соответствующую бизнес-требованиям (см. Комментарии @Stephen C.)

Answer 3

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

Answer 4

Для чего было бы полезно здание заранее? Если вас не интересуют вопросы работы и длительных бизнес-операций, тогда ваша стратегия лучше всего подходит для вашей ситуации ...

Answer 5

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