在我当前的项目中，业务逻辑是在存储过程（其中有 1000 多个）中实现的，现在他们希望随着业务的增长对其进行扩展。架构师已决定将业务逻辑移至应用层 (.net) 以提高性能和可扩展性。但他们并没有重新设计/重写任何东西。简而言之，从 SP 触发的相同 SQL 查询将从使用 ADO.Net 的 .net 函数触发。这怎么能产生任何性能？
据我所知，当我们需要独立于数据库或者有一些业务逻辑可以用 OOP 语言比 RDBMS 引擎更好地实现时，我们需要将业务逻辑移动到应用程序层（比如遍历层次结构或一些图像处理， ETC..）。其余的情况，如果没有复杂的业务逻辑需要实现，我认为还是把业务逻辑放在DB本身比较好，这样至少可以避免应用层和DB之间的网络延迟。
请让我知道你的看法。我是一名开发人员，在考虑一些架构决策时有点犹豫，请原谅我对这个主题的无知。
诸如此类的架构论点通常需要考虑许多权衡，孤立地考虑性能，或者仅考虑性能的一个方面（例如响应时间）往往会错过更大的图景。
在数据库层执行逻辑和将数据传送回应用层并在那里处理之间显然存在一些权衡。数据运输成本与处理成本。当您指出业务逻辑的成本和复杂性将是一个重要因素时，要传送的数据的大小将是另一个因素。
可以想象，如果 DB 层变得繁忙，即使单独的响应时间增加，将处理卸载到另一层也可能允许更大的整体吞吐量。然后我们可以扩展应用层以处理一些额外的负载。您现在是否会说性能已经提高（更大的整体吞吐量）或恶化（响应时间增加了一些）。
现在考虑应用层是否可以实现有趣的缓存策略。也许我们获得了非常大的性能胜利——对于某些请求，数据库根本没有负载！
如果你的业务逻辑还在 SQL 语句中，那么数据库会做和以前一样多的工作，你不会得到更好的性能。（如果它不能像使用存储过程时那样有效地缓存查询计划，可能会做更多的工作）
为了获得更好的性能，您需要将一些工作转移到应用程序层，例如，您能否在应用程序服务器上缓存数据，并在不访问数据库的情况下进行查找或验证检查？
我认为这些决定不应该使用架构教条来证明是合理的。数据会更有意义。
诸如“所有业务逻辑都属于存储过程”或“一切都应该在中间层”之类的陈述往往是分别由知识仅限于数据库或对象的人提出的。判断时最好将两者结合起来，并在测量的基础上进行。
例如，如果您的一个过程正在处理大量数据并返回少量结果，则有一个论点说它应该保留在数据库中。将数百万行放入中间层的内存中，对它们进行处理，然后通过另一个往返更新数据库几乎没有意义。
另一个考虑因素是数据库是否在应用程序之间共享。如果是这样，逻辑应该保留在数据库中，以便所有人都可以使用它。
中间层往往来来去去，但数据永远存在。
我自己是个对象，但我会轻描淡写。
这是一个复杂的问题。我不认为非黑即白的陈述适用于所有情况。
正如其他人已经说过的，这取决于许多因素。但是从您的问题来看，架构师似乎提议将存储过程从数据库内部移动到应用程序内部的动态 SQL。这对我来说听起来很可疑。SQL是一种面向集合的语言，需要大量数据记录的业务逻辑在SQL中会更好。想复杂的搜索和报告类型的功能。另一方面，带有相应业务规则验证的行项目编辑最好用编程语言完成。在应用层缓存缓慢变化的数据是另一个优势。如果您有专门的中间层服务作为所有数据的网关，那就更好了。如果数据直接在不同的应用程序之间共享，那么存储过程可能是一个好主意。您还必须考虑组织中 SQL 人才与编程人才的可用性/经验。这个问题真的没有一般的答案。