实体框架最佳实践:什么层应该调用saveChanges()?

我目前对此问题的看法是,在验证数据之后,始终让业务逻辑层调用保存更改。当用户单击保存按钮时,我将需要验证的任何实体传递给BLL,它决定是否保存更改()。

我和你一样好奇,想看看别人怎么说,因为这个问题(还有许多其他问题)一直困扰着我,因为我从英孚开始。

关键是分离数据库和服务语言。如果实用程序方法需要保存更改,那么它会保存更改,如果不保存,则说明它不会保存更改,并且需要执行其他步骤。实用程序不应具有名为savechanges的方法,它应具有与进程相关的方法,如startprocess或loadtobatch。

将该实用程序视为更多的服务,而不考虑数据库。“flagforApproval”听起来像一个数据库操作,请尝试将该方法视为类似于“startApprovalProcess”或其他与流程相关的方法。StartApprovalProcess将完成所有工作和提交。

如果存在多个步骤,则使每个步骤间接指示可能存在更多步骤。只有最后一步提交。尽管最后一步要做的是保存更改,但make的读取过程与move或start等过程类似。

前任:

1. 加载到ATCHAPProval(myEntityObject eo)

2. 验证ApprovalBatch()…

3. 移动批处理()…

我不确定是否有正确或错误的答案,但是让flagforApproval处理启动工作流的过程会让人感觉更干净(imo)。这包括告诉数据层保持对象的状态(即保存更改)。但是,这假定您有业务需求,声明一旦工作流启动,状态就应该被持久化,因此如果发生某种情况(即服务器崩溃),工作流过程将从最后一步继续进行。