业务逻辑应该写在哪里？在前端（业务层）还是在存储过程中？

Question

我正在编写一个带有 SQLServer 数据库的 ASP.NET 应用程序，我必须在其中计算应用程序成员的费率。这些计算影响超过 10 个数据库表。

我相信我有两个选择：

1. 在数据访问层中，从数据库中的第一个表中获取成员的数据并将其返回到业务层。到达那里后，对获取的数据执行一些计算以生成要保存在第二个表中的新数据。最后回调到数据访问层保存结果。然后，重复整个过程，从第二个表中提取信息来计算结果，并将结果保存在第三个表中，并对所有必要的表继续执行此操作。

2. 使用存储过程封装在数据库事务中正确表中计算和保存成员的新费率。

您认为哪种选择最好，为什么？如果我使用第一个选项，我应该如何从业务逻辑层执行一个 ADO.NET 事务中的所有插入和更新？我目前被禁止在数据访问层之外使用 ADO.NET 事务。

Answer 1

在我看来，这取决于需要对性能和模块化设计给予多少优先级。

如果这是一个交易应用程序，我必须从不同的表中即时计算价格，我会使用存储过程

• 对于一定量的负载有更好的性能，但当查询太多时，分布式数据库就变得至关重要
• 一个缺点是如果您想将来移动到不同的数据库（在大多数情况下人们不会），那么您必须将存储过程移植到新数据库中。

我的另一个选择是将大部分值保留在分布式数据库中缓存（如 memcache）并在业务中进行计算 层。

• 这些值将被预先填充到缓存中，并且当发生更改时缓存将被刷新。
• 这在消除数据库依赖性方面提供了灵活性。

但在我看来，您的操作在功能上非常依赖数据库，并建议使用存储过程路线。如果你认为缓存的第二种选择是可能的，那么值得一试。