對於一個乾淨的數據模型，我來回在這...實體框架最佳實踐：什麼層應調用SaveChanges（）？
使用審批工作流程作爲一個例子，讓我們在我的web應用程序說我有一個頁面，讓用戶標記一個MyEntityObject爲批准。 MyEntityObject有一些屬性可以控制其審批工作流程，所以我有一個常見的實用方法，名爲FlagForApproval(MyEntityObject eo)。
如若頁面呼叫FlagForApproval（）只設置必要的屬性，然後調用的SaveChanges （），當它準備好了，還是應該FlagForApproval（）保存更改？
使用實用方法保存更改看起來好像比要求做的要多一點（如果它只是一系列操作中的一步？），但同時使頁面調用SaveChanges（ ）並將數據提交給數據庫似乎可能被認爲太接近數據層責任。
想法？
（更新：FWIW，到目前爲止，我一直有實用方法調用的SaveChanges（），這樣的頁面只有一組異常處理，是否驗證或數據。）
我對這個電流意見問題是在驗證數據後總是讓業務邏輯層調用保存更改。當用戶點擊Save按鈕時，我將需要驗證的任何實體傳遞給BLL，並決定是否SaveChanges（）。
我和你一樣好奇，看看別人怎麼說，因爲這個問題（和其他許多問題）自從我開始使用EF以來一直困擾着我。
我不確定是否有正確或錯誤的答案，但是讓FlagForApproval處理啓動工作流的過程感覺更清晰（imo）。這包括告訴DataLayer保持對象的狀態（即SaveChanges）。但是，這假設您有業務需求，說明一旦啓動工作流程，狀態應該被保留，因此如果發生什麼事情（即服務器崩潰），工作流程過程從最後一步繼續。
關鍵是分開數據庫和服務語言。如果實用程序方法需要保存更改，那麼它確實如果沒有明確說明它不需要，並且需要執行其他步驟。該實用程序不應該具有名爲SaveChanges的方法，它應該具有與過程相關的方法，如StartProcess或LoadToBatch。
將該實用程序視爲更多服務並且不認爲數據庫。 「FlagForApproval」聽起來像是一個數據庫操作，試着將方法想象成類似「StartApprovalProcess」或其他過程相關的東西。 StartApprovalProcess將完成所有工作和提交。
如果有多個步驟，請使每個步驟間接指示可能會有更多步驟。只有最後一步提交。儘管最後一步可以做的是保存修改，使得像移動或啓動過程一樣被讀取。
例：
LoadToBatchApproval（MyEntityObject EO）
ValidateApprovalBatch（）...
MoveBatchToProcessing（）...
我認爲你是100％正確的 - 這是非常乾淨，以保持在調用SaveChanges BLL，讓它決定是否執行保存或不。但我可以看到至少有兩種情況，哪裏可以發生異常： 1）該項目需要在模型方面進行驗證 - 它不是BLL，而是必須確定是否應該保存更改。 2）SaveChanges是在真正簡單的代碼（添加實體，更新現有實體的單個屬性）後執行的。在我的情況下，它將是DAL。 所以我想最好的解決方案是遵循你的直覺和/或經驗。 – 2010-01-16 17:01:58