c# - for-each循环中的dbcontext.Savechanges（），最佳实践

我推荐的最佳实践是不要在一个类中混合使用这种功能。这与“单一责任原则”有关，该原则建议让班级做一件事。它也被描述为具有更改理由的一类。

以下是我们混合使用时发生的一些事情：

我们需要切换到其他数据库或ORM。这可能是一项重要的工作，但现在我们还需要处理电子邮件发送代码。我们将其移动到新的数据库代码中吗？它会去哪里？现在，这种变化更加复杂。
当我们修复电子邮件代码或数据库代码中的错误时，我们还触及了另一件事的代码，因为它们属于同一类，甚至是相同的方法。有可能将缺陷引入我们甚至不需要更改的地方。
同时进行测试变得更加困难。想象一下，如果每次您触摸数据库代码时都必须确保将记录写入数据库并发送电子邮件。如果更改数据库代码也是如此。

这样的问题是不可能的-它们几乎是不可避免的，除非我们只编写一次代码并且不再需要更改它。当方便时，它们不会发生。

将这样的事情分开会使我们（和下一个人）的生活更加轻松，因为它减少了我们必须思考和处理的无关的事情的数量。

一种方法是将所有更改作为事务的一部分保存到数据库中。在保存所有更改之前，事务不会提交或最终确定。如果您的数据被部分保存，则电子邮件只是问题的一部分。

如果您的应用程序执行了保存更改的代码，并且在返回时没有引发异常，则表示所有所有都已保存。然后，您可以发送电子邮件（使用专门为此目的编写的单独代码）。如果某些更改失败，则可以回滚数据库更改，但是如果您开始发送电子邮件，则不能回滚这些更改。

为进一步阅读，我将寻找结合“工作单元”和“交易”的文章和答案。这是实体框架常用的模式。 This example与Web应用程序直接相关。