在我的工作中，我有一个朋友坚持使用存储过程将业务逻辑保留在数据库中......
我可以用什么论据说服他不要这样做？
他想要这样做的原因是因为我们有多个具有不同平台的系统（.NET 中的 Web 应用程序与 VB.NET 和另一个在 Power Builder - Sybase 中开发的桌面应用程序）。
谢谢！
问问题
314 次
5 回答
3
我可以用什么论据说服他不要这样做？
你反对它的理由是什么？为什么一定要远离存储过程？
这实际上不是一个坏主意。如果您有用不同语言编写的不同系统访问数据库，那么将至少一些业务逻辑保留在数据库中可能会有所帮助。
于 2010-02-12T10:44:12.923 回答
2
我会选择网络服务有几个原因：
- 您可以将您的服务公开给所有类型的客户以使用它
- 它更灵活，更方便调试，用于测试
- 您将获得更好的源代码控制支持
- 您的编程语言可能比 SQL 更具表现力
于 2010-02-12T10:44:20.560 回答
2
- 不是强类型的。
- 不能轻易重构，在运行时破坏客户端。
- 不可单元测试。
- 很可能并非所有业务逻辑都可以是存储过程，因此您的逻辑在数据库和代码之间拆分。
- 存储过程不如编程语言强大或强大
- 更难获得正确的封装级别，要求您的客户了解数据模式的内部结构
- 更难版本
- 业务逻辑与数据库供应商相关联，您将终身受用
Edit: other user-contributed points:
- 扩展更难、更昂贵
于 2010-02-12T10:44:46.450 回答
2
专业网络服务，反对数据库逻辑：
- 如果您的数据库被其他人共享，那么如果您将逻辑放入数据库，那么您的应用程序现在将在数据层和逻辑层耦合。这通常是一件坏事。
- 我会担心数据库服务器上的负载。如果您的关系数据库受到查询和计算的影响，您将无法像中间层进行计算那样轻松地对其进行扩展。
Pro 数据库逻辑，con Web 服务：
- 如果数据库完全归您的应用所有，那么将逻辑放入其中可能是一个可以接受的选择。
- 我不太担心切换数据库的恐惧，因为这种情况比中间层更改更少发生。中间件时尚来来去去，但数据是任何企业的皇冠上的明珠。
- Web 服务也有其缺点。将 XML 转换为对象并返回是浪费 CPU 周期。内存调用比网络调用快几个数量级。今天到您的“简单”服务的单次往返可能需要 200 毫秒，但开始添加这些，很快您的 SLA 就会消失。
不要屈服于教条。考虑两者的优缺点，并根据您应用的具体情况做出合理的决定。你和你的同事听起来都像是做出了一个非黑即白的情感决定。请记住：结果并不反映您作为一个人。在它投入生产后，你会发现它对你作为设计师的评价。
于 2010-02-12T11:11:55.973 回答
1
无论如何，您只需使用数据库来做它最擅长的事情。聚合和数据完整性之类的东西。
但每个系统都是妥协。如果您有 5 组不同的客户端，那么数据库可能是最好的地方。并非每个电子表格或 Access DB 都可以调用您漂亮的中间层 Web 服务...
于 2010-02-12T10:57:33.817 回答