我正在努力处理以下用例：EF4 ASP.NET - 管理HTTP帖子和回滚之间的实体编辑
用户修改现有订单。订单很复杂 - 很多相关的“实体”（地址，邮政选项，供应商，品牌，型号，各种物品等）。跨多个http帖子。
用户想要放弃更改。
-
我有一个订单实体，如用户在编辑此我提出到实体关联的各种变化例如改变order.address，order.items.add（项目）...
在一篇文章中，这很好，但是在帖子之间我不知道如何最好地存储状态。如果我存储这些实体，那么我不能保存这些更改，因为它们跨不同的数据上下文。我已经读到，将数据上下文存储在会话状态（即长期上下文）中是不好的做法。每次编辑/发布后我都无法保存更改，因为我无法回滚（？）。我真的很想在编辑过程中与实体一起工作，而不是在最后一个大的保存（将UI设置并将其应用于一个块中）。
这肯定是一个很常见的问题 - 这让我很生气。任何帮助真的很感激。
干杯！
我们有一个类似的问题，我们通过多页向导构建复杂的业务对象。
不是在向导的每一步创建一个部分完整的业务对象，而是创建一个与业务对象非常相似的专用向导对象，通过向导填充该对象。在向导的每一步中，向导对象都会保存到数据库中。最后，用户可以接受它，并将其转换为真实的业务对象，然后变得对其他人可见，或者他们可以将其删除，并且没有人知道它存在。
如果这种方法不适合，我怀疑你正在寻找某种差异跟踪，无论是在实体还是数据库级别。在系统中执行，使用或管理都很简单。前者是某种计算和存储n更改实体并开发一个算法撤消它们，后者取决于您的RDBMS，但可能包含版本化行或类似行。
是的，它对我们来说很常见。在大多数情况下，我们使用MVC方法。即使没有实际的ASP .NET MVC项目，我们也可以使用类似的ViewModel与我们的Views/Pages/Scenarios等，其中没有直接/单个实体映射到业务层（换句话说，Business.Entities）。这与DTO非常相似。
它总是很容易使用断开EF。我们检索数据并放弃上下文，然后根据需要将实体转换为ViewModels/DTO。当你需要坚持修改时，你所要做的就是创建一个新的上下文，找到最新的实体实例进行修改。
Views/Pages/Controllers将管理这些ViewModels/DTOs。跟踪更改和删除的内容可以通过引入HistoryList<T>（您可以扩展List<T>来实现此目的）来完成。
完成后，使用Controller/Workflow/Component，您可以观察ViewModel/DTO，并使用新的上下文对您的实体进行必要的更改以检索并保留。
它涉及到一点编码，我会说它不是一个完美的解决方案，因为它有它自己的优点和缺点。
/KP
您是否使用自追踪实体？如果是这样，你可能可以将它们保存到视图状态，也就是说，如果你知道它们不会变大。 – 2010-07-27 20:47:02