假设您有一个基于用户输入的某些数字的Web应用程序，当他/她单击一个按钮时，会给他另一个数字（超过简化）。所有的数据都存储在SQL服务器中。现在，我可以将所有必需的数据提供给业务访问层并在那里进行计算。或者在数据库中进行存储proc的计算并将结果发送给应用程序。我非常喜欢后者，因为我觉得它更容易。但有些人可能会认为所有的业务逻辑必须位于应用程序的业务层。我觉得如果应用中有任何业务逻辑，它就属于业务层。但是您不必在应用中拥有与数据相关的业务逻辑。asp.net应用程序中的业务层
专家会推荐什么？
如果我可以改一下你的问题，我想你会问：“我应该把我的业务逻辑在TSQL或C＃？”
就个人而言，我强烈建议C＃（或vb.net，如果这是你使用的是什么）。作为编程工具，它比tsql提供了更多的功能。当我说权力时，我的意思是写出易于理解，合乎逻辑，组织良好的自我记录代码的能力，更重要的是易于维护。面向对象的技术（如抽象类和接口）允许您创建不仅可重用的代码片段，还允许您实施易于追踪的业务逻辑。这可以通过存储过程来模拟，但是最终你会通过循环来实现它，然后在出现问题时追踪它。
与SQLserver相比，代码库更容易与VS集成，并且更改管理甚至本地开发环境维护变得更加困难，因为当事情集中在一个数据库太大而无法在本地运行而不是更新时一个开发人员本地C＃代码的工作副本。
当然，在一个单一的开发情况下，当没有人会永远在这个应用程序，协同工作和变更管理方面的考虑相比，开发人员的舒适性与TSQL VS任何其他工具苍白。
最后，只是因为C＃提供了丰富的语言功能，不是每个人都使用它。我可以（也有!!）写1000行C＃方法，就像我可以写1000行存储过程一样容易。
希望这会有帮助， Lawrence
你也可以做。如果您想要在不触摸数据库的情况下发送数字，那么您需要在业务层中进行计算。业务层是一个好地方，因为它比存储过程更易于调试，并且可以进行单元测试。