我目前正在使用一个在线应用程序，需要多个屏幕/步骤才能完成。应用程序域使用对象图建模。使用ORM包完成数据库的持久性。
当我浏览屏幕时，我建立了对象图。在屏幕之间，我将对象图序列化/反序列化为当前会话。当我到达最终屏幕时，对象图已完成，我将其存储在我的数据库中。
我的问题如下。我并不十分关注工作单元等模式。我只是想知道是否事先构建了对象图，然后在我进入屏幕时进行填充，最后保存它是一个可行的策略。或者可能通过屏幕填充/序列化/反序列化单个对象，然后在持久化到数据库之前构建最终对象图可能更有意义。或者，如果有一个更好的方法。
我选择暂时继续参加会议，因为我收集了这些内容，因为如果用户放弃该过程，它将会过期，我将不必搜索数据库来清除已放弃的应用程序。 / p>
我希望我的问题足够明确。这似乎很常见。
修改
我对我的对象图方法的主要关注是，虽然我在我的域模型中工作，但我觉得每次我需要更新其中的一部分时，我会产生反序列化/序列化整个图形的成本。也许我应该在我的屏幕和最终的域模型之间进行中间抽象。我正在使用ASP.NET / C＃作为我的实现平台。
答案 0 :(得分：2)
我认为在HTTPSession中构建会话状态并在最后提交是完全有效的。如果您需要在此方案中进行故障转移，则可以始终使用Terracotta clustered sessions，这将在Terracotta服务器中存储您的HTTPSession状态（具有不同级别的持久性）。然后，具有会话的服务器可以死亡，Terracotta可以在另一个节点上恢复它。
您也可以查看Spring Webflow - 它处理流状态下的这种情况（也存储在会话中）。
答案 1 :(得分：1)
我个人会选择
通过屏幕填充/序列化/反序列化单个对象，然后在持久保存到数据库之前构建最终对象图
有两个原因。首先，如果您使用较小的模块构建应用程序并在最后将对象图形拼凑在一起，则应该使单元测试更容易，并允许重用零件/屏幕流程。
其次随着需求的变化，您很可能需要备用屏幕流，这意味着您无法预先构建对象图并需要随时构建对象。
在发布我的回答时，我假设您选择了合适的技术模型以满足业务需求（请参阅@Stephen C的评论）。
答案 2 :(得分：1)
我最后一次编写这样的应用程序时，每个步骤都有一个独特的模型 - 数据实体和用户界面之间的一对一关系（主要是）。保持对象小和工作流程绑定使得更改单个步骤或重新排序工作流程变得更加容易，而不会强制重写应用程序。
答案 3 :(得分：0)
我想说，您当前的方法存在一个可能的（高级别）问题，即用户的工作直到最后才会保存。如果屏幕需要很长时间才能完成，这并不好。
答案 4 :(得分：0)
预先建造什么有益？如果您不关心工作单元和长期业务交易问题，那么您的策略最适合您的情况......