4

我总是会再次遇到关于将业务逻辑放置在何处的讨论：在应用程序代码中的业务层内或在存储过程方面在 DB 中。我个人倾向于第一种方法，但我想先听听你的一些意见，不要用我的个人观点影响你。我知道不存在一刀切的解决方案，它通常取决于许多因素，但我们可以讨论一下。

顺便说一句，我们在 Web 应用程序的上下文中（拥有一个 Oracle DB），我们目前的方法是拥有

  • UI 层，它接受 UI 输入并执行第一个客户端验证
  • 具有许多服务类的业务层，其中包含业务逻辑，包括对用户输入的验证（服务器端）
  • 数据访问层，它从数据库调用存储过程以执行持久性/读取操作

然而，许多人倾向于根据存储过程将业务层的东西（尤其是关于验证）移到数据库中。

你怎么看待这件事？我想讨论一下。

4

4 回答 4

2

无论是否有人在使用您的应用程序、另一个应用程序或 SQL 工具，让数据保持自己的理智本身就很有价值。

得到一个永远不应该为 NULL 的值？- 好，设计数据库来执行该规则。在两个应该始终存在的表之间建立关系？- 好，放一个外键约束。

有在您的问题域中应该是唯一的值吗？- 很好，加入一个唯一的约束。得到一个应该始终在 6-10 个字符之间的字符串？- 好，添加一个检查约束。

这些都是基本的，很容易添加到数据库中，并且给你一定程度的信心，当你的应用程序试图从数据库中加载一些人手破坏的东西时，它不会崩溃。在某种程度上，它们可以被认为是业务逻辑。（毕竟，所有这些都是从有关您的问题领域的具体事实中得出的）。

所以在那个程度上，我会把这种业务逻辑放在数据库中。是的，在您的应用程序中，您希望应用类似的检查，以提供更愉快的用户体验。但我宁愿让我的应用程序在尝试将无效内容放入数据库时​​（作为最后手段）崩溃，也不愿在 6 个月后发现这一事实。

于 2010-03-24T07:17:55.620 回答
1

数据库中的逻辑是维护的噩梦。在真正需要它的情况下，应该将其记录好，并将其与其他源代码一起以文本格式放置。

于 2010-03-24T06:56:24.233 回答
1

我只见过一种情况，存储过程中的逻辑是有意义的；基本上它与性能有关：需要移动和处理大量数据。可取之处在于逻辑并不是非常复杂 - 但 SP 仍然是一场噩梦。在应用程序代码中这样做被认为太慢了。

所以猜测一下 - 这可能是 50 多个项目中的 1 个？

您定义的因素将是：

  • 所有权：谁（哪个系统/组件）拥有数据，谁拥有适用于它的规则/逻辑？如果数据库由特定组件“拥有”，那么它应该包含业务逻辑，因为数据库只是它的存储库；如果数据库本身就是一个实体，那么可能还有一个案例可以在其中封装逻辑。您甚至可能有一个更微妙的中断，其中某些决定是在一个地方做出，而其他决定是在其他地方做出的——触发器就是一个可能的例子。
  • 可管理性：应用程序代码中的逻辑 - 更好的测试支持等。
  • 复杂性：（链接到可管理性）应用程序代码中的逻辑。
  • 性能：如果数据量很大，并且使用应用程序代码太慢，您可能会被迫将其放在那里。
  • Consistency: all in app code - and hope you don't have any performance issues. make sure you document exceptions very well.
于 2010-03-26T01:30:09.460 回答
0

由于各种原因，它通常很糟糕。如果您使用面向对象的工作，那么存储过程就不是逻辑的好地方 - 因为您的对象不再存在。一个对象可能在多个表中。

第二。SQL 是一种用于编写复杂逻辑的非常糟糕的语言。它只是没有完成 - SQL Server 允许用 .NET 编写 SP 的原因之一。尝试在 SQL 中计算哈希，你就会明白我的意思——各种字符串操作是另一个领域。脏得要命。

SP 通常是用愚蠢的论点来完成的。像人们为他们辩护的论点这样愚蠢的论点根本不是真的。Frans Bourma 在http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx上列出了最常用的谬误并很好地解释了为什么这些论点大多是愚蠢的胡言乱语- 是的，它是这种程度的白痴（就像人们甚至没有阅读文档或考虑他们实际所说的话，在所有后果中）。

我个人使用存储过程的系统有限，我拥有的系统是： 复杂性有限，但性能高。基本上没有继承，因为对象模型很简单，SP 中的事务逻辑并不太复杂，而且我需要/想要极小的锁定速度，所以某些操作被移到存储过程中。最重要的是，这个特定的应用程序也有一个非常不寻常的对象模型（对象是从各种来源动态流式传输的，从不更新，总是替换，所有更改都必须通过服务而不是在对象上完成 - 有时因为更改是在另一个组织的另一个国家的另一台计算机上“要求”。

一个很好的例子是一个高性能的会计系统（因为它正在跟踪来自全自动交易系统的交易）。每个 SP 中的逻辑并不是很复杂，但我希望尽可能少的 SQL 来回运行。

现在，存储过程的坏方面也很明智。没有适当的测试框架，没有模拟框架，源代码控制 itnegration 有点尴尬（但可以使用正确的工具集）。集成调试？好吧，我非常感谢 Microsoft 和 Visual Studio - 这确实有效（存储过程中的断点 - 非常好）。

我还没有看到一种使用大量存储过程的方法，这种方法没有用完全无聊的论据来辩护——实际上是在证明“员工应该被解雇”的思维水平。也许他们在外面，但我没有看到他们。

于 2010-03-24T07:07:28.673 回答