对于干净的数据模型，我来回此...
使用批准工作流程作为示例，假设在我的Web应用程序中，我有一个页面，允许用户标记MyEntityObject以获得批准。 MyEntityObject有一些控制其审批工作流程的属性，因此我有一个名为FlagForApproval(MyEntityObject eo)的常用实用工具。
页面是否应调用 FlagForApproval（）来设置必要的属性，然后在准备就绪时调用 SaveChanges（），或者 FlagForApproval（）保存更改？
使用实用程序方法保存更改似乎比它要求做的更多（如果它只是一系列操作中的一步？），但同时，使页面调用SaveChanges（）并且将数据提交给数据库似乎可能被认为过于接近数据层职责。
思想？
（更新：FWIW，到目前为止我一直在使用实用程序方法调用SaveChanges（），这样页面只有一组异常要处理，无论是验证还是数据。）
答案 0 :(得分：2)
我目前对此问题的看法是，在验证数据后，始终要让业务逻辑层调用保存更改。当用户单击“保存”按钮时，我将需要验证的任何实体传递给BLL，并决定是否要保存更改（）。
我和你一样好奇，看看别人怎么说，因为自从我开始使用EF以来，这个问题（和许多其他问题）一直困扰着我。
答案 1 :(得分：1)
关键是分离数据库和服务语言。如果实用程序方法需要保存更改，那么它确实如果没有明确表示没有更改，则需要执行其他步骤。该实用程序不应该有一个名为SaveChanges的方法，它应该有与进程相关的方法，如StartProcess或LoadToBatch。
将该实用程序视为更多服务而不考虑数据库。 “FlagForApproval”听起来像一个数据库操作，尝试将该方法视为“StartApprovalProcess”或其他与进程相关的东西。 StartApprovalProcess将完成所有工作和提交。
如果有多个步骤，请使每个步骤间接指示可能有更多步骤。只有最后一步提交。尽管所有最后一步可能都是保存更改，但make会像移动或启动等过程一样被读取。
前：
LoadToBatchApproval（MyEntityObject eo）
ValidateApprovalBatch（）...
MoveBatchToProcessing（）...
答案 2 :(得分：0)
我不确定答案是对还是错，但让FlagForApproval处理启动工作流程的过程感觉更清晰（imo）。这包括告诉DataLayer持久化对象的状态（即SaveChanges）。但是，这假设您有业务要求，说明一旦工作流启动，状态应该保持不变，因此如果发生某些事情（即服务器崩溃），工作流程将从上一步继续。