让我们想象一下在网站上执行的任何常见操作。
用户按下按钮后，应用程序应该：
这是业务逻辑层的关注点，因为它写在大量书籍中。实际上，我们首先从 DB 中读取数据，然后将数据写入 DB。如果在我们检查期间任何其他用户/进程更改了数据，我们会将无效结果放入数据库中。似乎这个问题应该是众所周知的，但我仍然找不到好的解决方案。
问题是：为什么我们需要没有机会维护业务事务的业务逻辑层？
你可能会说 TransactionScope。那么，您如何防止读取数据被外部进程更改？如何从业务层升级锁定？如果有可能，那么它不会比在存储过程中进行事务更昂贵吗？
无法将部分逻辑带入数据库 - 只有整体。第 1 部分和第 2 部分必须在同一个事务中实现，此外，必须锁定读取数据，直到进行更新。
想法？
我真的认为你从错误的角度争论这个问题。首先，在您的具体示例中，似乎没有任何迹象表明一个用户的投票变化会使另一个用户影响投票的尝试无效。所以，如果我打开页面，有 200 票投给了该项目，然后我点击了 upvote，我真的不在乎其他 10 个人是否同时做了同样的事情。因此，验证可以由业务层运行，如果结果是投票可以通过，则可以使用单个 SQL 语句以原子方式完成更新（例如 UPDATE Votes SET VoteCount = VoteCount+1 WHERE ID= @ID)，或者带有 UPDLOCK 的选择并更新包装在事务中。ORM 和开发人员采用后一种方法的趋势既不存在也不存在，
现在，如果要求对投票计数的更新实际上使我的投票无效，那么情况就完全不同了。在这种情况下，我们使用乐观或悲观并发是绝对正确的，但这些（显然）不适用于数百人可能同时为同一个项目投票的网站。这里的问题不是实现，而是允许多人处理同一个项目的本质。
因此，总而言之，没有什么能阻止您在数据库之外拥有一个业务层并保持增量原子性。同时，您希望享受将业务逻辑置于数据库之外的好处（这本身就是一篇文章，但我认为这是一个很大的好处）。