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