“将业务逻辑移动到应用层”可以提高性能吗？

Question

在我目前的项目中，业务逻辑是在存储过程（1000多个）中实现的，现在他们希望随着业务的增长而扩展它。架构师已决定将业务逻辑移至应用层（.net）以提高性能和可扩展性。但他们并没有重新设计/改写任何东西。简而言之，使用ADO.Net从.net函数触发从SP触发的相同SQL查询。这怎么能产生任何表现？

据我所知，当我们需要数据库独立性时，我们需要将业务逻辑移动到应用程序层，或者有一些业务逻辑可以在OOP语言中比RDBMS引擎更好地实现（比如遍历层次结构或某些层次结构）图像处理等。）。在其他情况下，如果没有复杂的业务逻辑可以实现，我认为最好将业务逻辑保留在DB本身中，至少可以通过这种方式避免应用层和DB之间的网络延迟。

请告诉我您的看法。我是一个开发人员，有点犹豫地看着一些架构决策，原谅我对这个主题的无知。

Answer 1

诸如此类的架构论据通常需要考虑许多交易，考虑单独的性能，或者只考虑性能的一个方面，例如响应时间往往会错过更大的图片。

在数据库层中执行逻辑和将数据发送回applciation层并在那里处理它之间显然需要权衡。数据运输成本与处理成本。当您指出业务逻辑的成本和复杂性将是一个重要因素时，要发送的数据的大小将是另一个。

可以想象，如果DB层变得繁忙，即使个别响应时间增加，卸载到另一层的处理也可以允许更大的总吞吐量。然后我们可以扩展App层以处理一些额外的负载。您现在可以说性能已经提高（总吞吐量更高）或更差（响应时间增加）。

现在考虑应用层是否可以实现有趣的缓存策略。也许我们获得了非常大的性能胜利 - 对于某些请求，DB根本没有负载！

Answer 2

如果您的业务逻辑仍在SQL语句中，那么数据库将执行与以前一样多的工作，并且您将无法获得更好的性能。 （如果无法像使用存储过程那样有效地缓存查询计划，可能会更有效）

为了获得更好的性能，您需要将一些工作转移到应用程序层，例如，您可以在应用程序服务器上缓存数据，并在不访问数据库的情况下进行查找或验证检查吗？

Answer 3

我认为这些决定不应该用建筑教条来证明。数据会更有意义。

“所有业务逻辑属于存储过程”或“一切应该位于中间层”之类的语句往往分别由知识限于数据库或对象的人员制作。最好在判断时将两者结合起来，并在测量的基础上进行。

例如，如果你的一个程序正在处理大量数据并返回一些结果，那么就会有一个论点说它应该保留在数据库中。将数百万行放入中间层的内存，处理它们，然后再往返更新数据库是没有意义的。

另一个考虑因素是数据库是否在应用程序之间共享。如果是这样，逻辑应保留在数据库中，以便所有人都可以使用它。

中间层倾向于来去，但数据仍然永远存在。

我自己就是一个对象，但我会轻描淡写。

这是一个复杂的问题。我不认为黑白语句会在每种情况下都有效。

Answer 4

正如其他人已经说过的那样，这取决于很多因素。但是从你的问题来看，架构师似乎建议将存储过程从内部DB移动到应用程序内部的动态SQL。这对我来说听起来很可疑。 SQL是一种面向集合的语言和业务逻辑，需要按摩大量的数据记录，在SQL中会更好。想想复杂的搜索和报告类型功能。另一方面，使用相应的业务规则验证的行项目编辑在编程语言中要好得多。缓存app层中缓慢变化的数据是另一个优势。如果您有专用的中间层服务作为所有数据的网关，那就更好了。如果数据直接在不同的应用程序之间共享，则存储过程可能是个好主意。 您还必须考虑组织中SQL人才与编程人才的可用性/经验。 这个问题确实没有一般的答案。