假设您有一个 Web 应用程序，当他/她单击按钮时，您会根据用户输入的一些数字给他另一个数字（过于简化）。所有数据都存储在 SQL Server 中。现在我可以将所有需要的数据送到业务访问层并在那里进行计算。或者在数据库存储过程中进行计算并将结果发送到应用程序。我非常喜欢后者，因为我发现它更容易。但是有些人可能会争辩说，所有的业务逻辑都必须在应用程序的业务层中。我觉得如果应用程序中有任何业务逻辑，它属于业务层。但您不必在应用中拥有与数据相关的业务逻辑。
专家会推荐什么？
【问题讨论】：
标签： architecture business-logic
如果我可以改写你的问题，我想你是在问，“我应该把我的业务逻辑放在 tsql 还是 c# 中？”
就个人而言，我强烈推荐 c#（或 vb.net，如果您正在使用）。作为一种编程工具，它为您提供了比 tsql 更多的功能。当我说权力时，我的意思是编写易于理解、逻辑、组织良好的自记录代码的权力，更重要的是，易于维护。抽象类和接口等面向对象技术不仅允许您创建可重用的代码片段，还允许您实施易于跟踪的业务逻辑。这可以用存储的过程来模拟，但你最终会跳过箍来实现它，然后在出现问题时跟踪它。
代码存储库的构建也比 SQLserver 更容易与 VS 集成，当事情集中在一个太大而无法在本地运行的数据库上而不是更新一个c# 代码的开发人员本地工作副本。
当然，在单个开发人员的情况下，当没有其他人在此应用程序上工作时，与开发人员对 tsql 和任何其他工具的舒适度相比，协作和变更管理方面的考虑就显得微不足道了。
最后，仅仅因为 c# 提供了丰富的语言特性，并不是每个人都使用它们。我可以（并且拥有！！）编写一个 1000 行的 c# 方法，就像我可以编写一个 1000 行的存储过程一样容易。
希望这会有所帮助， 劳伦斯
【讨论】：
你可以做任何一个。如果您想在不接触数据库的情况下分发数字，那么您会希望在业务层中进行计算。业务层是个好地方，因为它比存储过程更容易调试，并且可以进行单元测试。
【讨论】：