我需要知道在程序中保留业务层的缺点

Question

在我的工作中，我有一位朋友坚持使用存储过程将业务逻辑保留在数据库中......

我可以用什么论据来说服他不要这样做？

他想要这样做的原因是因为我们有多个具有不同平台的系统（使用VB.NET的.NET应用程序和使用Power Builder开发的另一个桌面应用程序 - Sybase）。

谢谢！

Answer 1

  

我可以用什么论据来说服他不要这样做？

你反对它的论点是什么？为什么你一定想远离存储过程？

这实际上并不是一个坏主意。如果您使用不同语言编写的不同系统访问数据库，则可能有助于在数据库中保留至少一些业务逻辑。

Answer 2

我会选择Web服务有几个原因：

• 您可以将您的服务公开给所有类型的客户使用它
• 它更灵活，更方便调试，用于测试
• 您将获得更好的源代码管理支持
• 您的编程语言可能比SQL
更具表现力

Answer 3

• 没有强烈打字。
• 无法轻易重构，在运行时断开客户端。
• 不可单元测试。
• 很可能并非所有业务逻辑都可以是存储过程，因此您的逻辑在数据库和代码之间分开。
• 存储过程不如编程语言强大或强大
• 难以获得正确的封装级别，要求您的客户知道数据架构的内部结构
• 更难版本
• 业务逻辑与数据库供应商联系在一起

Edit: other user-contributed points:

• 更难，更昂贵的规模

Answer 4

专业网络服务，数据库逻辑：

1. 如果您的数据库由其他人共享，那么如果您将逻辑放在数据库中，您的应用程序现在将在数据和逻辑层耦合。这通常是一件坏事。
2. 我会担心数据库服务器上的负载。如果您的关系数据库受到查询和计算的影响，您将无法像中间层进行计算那样轻松扩展它。

Pro数据库逻辑，con web services：

1. 如果数据库完全归您的应用所有，那么将逻辑放在其中是一个可以接受的选择。
2. 我不担心切换数据库的恐惧，因为这种情况比中间层更改更少发生。中间件时尚来去匆匆，但数据是任何企业的皇冠上的明珠。
3. Web服务也有其缺点。将XML转换为对象并将其转换回来是浪费CPU周期。内存中调用比网络调用快几个数量级。今天单次往返“简单”服务的往返时间可能是200毫秒，但是开始添加它们很快就会出现你的SLA。

不要屈服于教条。考虑两者的优点和缺点，并根据您的应用程序的特定情况做出合理的决定。你和你的同事听起来都像是一个黑人或白人的情感决定。请记住：结果并不反映在你身上。在生产之后，你会发现它作为一名设计师所说的关于你的内容。

Answer 5

Define business logic

无论如何，你只需使用数据库来做它最擅长的事情。像聚合和数据完整性这样的东西。

但每个系统都是妥协。如果您有5组不同的客户端，那么数据库可能是最佳位置。并非每个电子表格或Access DB都可以调用您漂亮的中间层Web服务......