EF4 ASP.NET-管理HTTP POST和回滚之间的实体编辑

我正在努力解决以下用例：

用户修改现有订单。订单是复杂的——有很多相关的“实体”（地址、职位选择、供应商、品牌、型号、各种物品等）。跨多个http帖子

用户希望放弃更改

--

我有一个订单实体，当用户编辑此实体时，我正在对实体关联进行各种更改，例如更改订单.地址，订单.项目.添加（项目）

在一篇文章中，这很好，但在不同的文章中，我不知道如何最好地存储状态。如果存储实体，则无法保存更改，因为它们跨越不同的数据上下文。我已经读到，将数据上下文存储在会话状态（即长期上下文）中是一种不好的做法。我无法在每次编辑/发布后保存更改，因为我无法回滚（？）。我真的希望在编辑过程中使用实体，而不是在最后进行一次大的保存（将UI设置应用到一块中）

这一定是一个很常见的问题——我快疯了。非常感谢您的帮助

---

干杯

在通过多页向导构建复杂业务对象时，我们遇到了类似的问题

我们不是在向导的每个步骤中创建一个部分完整的业务对象，而是创建一个与业务对象非常相似的专用向导对象，并通过向导进行填充。在向导的每个步骤中，向导对象都会保存到数据库中。最终，用户可以接受它，并将其转换为真实的业务对象，然后对其他所有人可见，或者用户可以将其存储起来，而其他任何人都不知道它的存在

---

如果这种方法不合适，我怀疑您正在实体或数据库级别上寻找某种差异跟踪。两者都不容易在系统中实现、使用或管理。前者是对实体的n个更改进行某种计算和存储，并开发一种算法来撤销它们，后者取决于您的RDBMS，但可能包括版本化的行或类似的行。

是的，这对我们来说非常常见。在大多数情况下，我们使用MVC方法。即使没有实际的ASP.NET MVC项目，我们也会在视图/页面/场景等中使用类似的ViewModel，其中没有直接/单个实体映射到业务层（换句话说，Business.Entities）。这与DTO非常相似

使用断开的EF总是很容易的。我们检索数据并丢弃上下文，然后在必要时将实体转换为ViewModels/DTO。当您需要持久化更改时，您所要做的就是创建一个新的上下文，找到最新的实体实例来进行更改

视图/页面/控制器将管理这些视图模型/DTO。通过引入

历史列表

（您可以扩展

列表

）来实现对更改和删除内容的跟踪

完成后，使用控制器/工作流/组件，您可以观察ViewModel/DTO，并使用新的上下文对实体进行必要的更改以检索和持久化

它涉及到一点编码，我想说这不是一个完美的解决方案，因为它有自己的优点和缺点

---

/KP

您是否使用自跟踪实体？如果是这样，您可能可以将它们保存到viewstate，也就是说，如果您知道它们不会变大的话。