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

Question

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

我相信我有两个选择：

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

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

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

Answer 1

IMO取决于性能和模块化设计需要多少优先级。

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

• 一定数量的负载可以提高性能，但是当查询过多时，分布式数据库就变得必不可少了
• 一个缺点是，如果您希望将来迁移到另一个数据库（大多数情况下人们没有），那么您必须将存储的proc移植到新的数据库

我将拥有的另一个选项是将大部分值保存在分布式缓存中（如内存缓存）并在业务层中进行计算。

• 这些值将预先填充到缓存中，缓存将在有更改时刷新。
• 这为删除数据库依赖性提供了灵活性。

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