我正在努力處理以下用例：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