Architecture 在何处放置业务逻辑的利弊：应用程序级还是数据库级

我总是会再次遇到关于将业务逻辑放在何处的讨论：在应用程序代码的业务层中，或者在存储过程的数据库中。就我个人而言，我倾向于第一种方法，但我想先听听你的观点，不要用我的个人观点影响你。我知道不存在一刀切的解决方案，这通常取决于许多因素，但我们可以讨论这个问题

顺便说一句，我们处于web应用程序的环境中（有一个Oracle DB），我们当前的方法是

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

然而，许多人倾向于将业务层的内容（特别是关于验证）从存储过程的角度转移到数据库中

---

你觉得怎么样？我想讨论一下。

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

由于各种原因，它通常很糟糕。如果您是面向对象的，那么存储过程就不是eaxactls逻辑的好地方——因为您的对象已经不存在了。一个对象可能位于多个表中

第二。SQL是一种非常糟糕的语言，无法编写复杂的逻辑。这并不是因为这个原因——SQL Server允许在.NET中编写SP的一个原因。尝试在SQL中计算散列，您就会明白我的意思——所有类型的字符串操作都是另一个领域。脏得要命

SP通常都是用愚蠢的争论来完成的。人们为他们辩护的那些愚蠢的论点根本就不是真的。Frans Bourma列出了最常使用的谬误，并很好地解释了为什么这些论点大多是愚蠢的漫无边际的——是的，就是这种程度的白痴（就像人们甚至不阅读文档或思考他们实际上说了什么，所有的后果）

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

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

现在，存储过程的不好的一面也是工具方面的。没有合适的测试框架，没有模拟框架，源代码管理。它的内化有点笨拙（但使用正确的工具集是可行的）。集成调试？好吧，我非常感谢Microsoft和Visual Studio，这确实有效（存储过程中的断点-非常好）

---

我还没有看到一种方法使用了大量存储过程，而这些存储过程并没有用完全错误的论点进行辩护——实际上是“员工应该被解雇”的证明思考的层次。也许它们就在那里，但我没有看到它们。

让数据保持自身的正常状态，无论是否有人在使用您的应用程序、其他应用程序或SQL工具，其本身都是有价值的

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

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

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

---

因此，在某种程度上，我会将这种业务逻辑放在数据库中。是的，在应用程序中，您希望应用类似的检查，以提供更愉快的用户体验。但我宁愿让我的应用程序崩溃（作为最后手段）当它试图将无效的数据放入数据库时，比6个月后发现这一事实要好得多。

我只看到过一种情况，即存储过程中的逻辑是有意义的；基本上是与性能相关的：大量数据需要移动和处理。令人欣慰的是，逻辑并不十分复杂，但SP仍然是一场噩梦。它是被认为太慢，无法在应用程序代码中执行此操作

那么，猜猜看，这可能是50%以上的塞纳里奥计划

您定义的因素将是：

• 所有权：谁（哪个系统/组件）拥有数据，谁拥有应用于数据的规则/逻辑？如果数据库是“拥有的”通过一个特定的组件，它应该包含业务逻辑，因为数据库仅仅是它的存储库；如果数据库本身就是一个实体，那么可能也有理由在其中封装逻辑