Asp.net mvc 3 MVC3在内存中保留复杂对象

我们有一个基于ASP.NETMVC3的web应用程序，用于索赔输入和管理。为了简化，将索赔视为订单。声明可以有子对象，其子对象之一可以有子对象。像

（即索赔-->项目-->文件）

我们需要一个类似事务的机制。也就是说，在索赔输入期间，用户可以添加/编辑/删除子对象或子对象。最后，他可以“接受”（提交）所有更改（到数据库）或“取消”（回滚/拒绝）所有更改

我有哪些选项可以在技术上实现这个支持接受/取消机制的“事务”特性。以下是我的一些想法-

获取整个Claim对象并通过序列化在会话中预先列出它。所有更改都将“在内存中”对此声明对象进行，最终用户可以决定接受/取消

为每个实体（xxxx）添加“xxxx\U运输”表。。所有操作将在此临时传输表上完成，提交后，我们最终将更改应用于实际xxxx表

淘汰方法-将索赔模型存储在客户端，对其应用更改。UI绑定将立即反映更改。最后，当提交时，将更改应用于数据库

我的评估

我们已经完成了，并且使用了ASP.Net会话状态服务，但是 对象序列化会影响性能

额外的复杂性值得吗？尤其是与#1的性能增益相比

我相信这将增加复杂性和操作性 GUI层上的处理。安全吗

你建议哪一个？如果有误导性，请忘记我的想法，并分享你认为最好的

---

谢谢。

您必须始终在一定程度上信任客户。一次把所有东西都放进去和一件一件地放进去有着同样的“安全性”。两者都需要正确验证。我正在进行我的第一个客户端驱动的Durandal/KO项目，我认为它工作得非常好。不要忘记，在后一种方法中，页面本身会影响对象的生存期-刷新->无更多数据。在设计用户体验时要考虑到这一点，比如分离步骤或使用检查点。我明白了。但在我的例子中，我有一些与对象相关联的文件上传。希望KO能在客户端保留对象层次结构，直到回发（接受），但我必须在用户选择文件时上载它们。东西是在两个地方维护的！除此之外，我还做了一些KO，它看起来的确是一种很棒的用户体验，但必须维护viewmodel实现，否则它可能会变得复杂！我没有做过文件，但这似乎并不难。使用异步上载技术（HTML5或iframes）并通过GUID或类似的nonce或ID关联文件。仅在客户端存储名称/GUID。服务器将在不久的将来接受“finish”请求，或者如果临时文件未在阈值内使用，则某些自动作业可以获取临时文件。