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