为什么业务逻辑？

Question

让我们想象一下在网站上执行的任何常见操作。

用户按下按钮后，应用程序应该：

1. 检查条件是否允许操作（用户权限，某些对象的一致性，关系和其他内容）
2. 更新数据库记录
3. 报告

这是商业逻辑层的关注点，因为它是用大量书籍编写的。 实际上，我们首先从DB读取数据然后将数据写入DB。如果在我们的检查过程中任何其他用户/进程更改了数据，我们会将无效结果放入数据库。看起来像这个问题应该是众所周知但我仍然找不到好的解决方案。

问题是：为什么我们需要业务逻辑层而没有机会维护业务交易？

你可能会说TransactionScope。那么，如何防止外部进程读取数据？如何从业务层UPDLOCK？如果有可能那么它不会比在存储过程中进行事务更昂贵吗？

无法将一部分逻辑带入数据库 - 只有整体。 ＃1和＃2部分必须在同一事务中实现，而且必须锁定读取数据，直到进行更新。

想法？

Answer 1

我真的认为你是从错误的角度来论证这一点。首先，在您的具体示例中，似乎没有任何说明一个用户的投票变更使另一个用户尝试影响upvote的行为无效。所以，如果我打开页面，并且该项目有200票，我点击了upvote，我真的不在乎其他10个人是否同时做了同样的事情。因此，验证可以由业务层运行，如果结果是投票可以通过，则可以使用单个SQL语句以原子方式完成更新（例如UPDATE Votes SET VoteCount = VoteCount + 1 WHERE ID = @ID），或包含在事务中的UPDLOCK和更新的选择。 ORM和开发人员采用后一种方法的趋势既不存在也不存在，如果您愿意，您仍然可以选择更改实现。

现在，如果要求是对投票计数的更新实际上使我的投票无效，那么这是完全不同的情况。在这种情况下，我们绝对正确使用乐观或悲观并发，但这些（显然）不适用于数百人可能同时为同一项目投票的网站。这里的问题不是实现，而是允许多个人处理同一个项目的本质。

因此，总而言之，没有什么可以阻止您在数据库之外拥有业务层并保持增量原子性。与此同时，您希望享受在DB之外拥有业务逻辑的好处（这本身就是一个帖子，但我认为这是一个很大的好处）。