是应该在应用程序层和数据库层中实施业务规则，还是只在其中一个中实施？

Question

我一直在我的应用程序层（模型）和数据库层（引发错误的存储过程）中实施业务规则。

由于以下几个原因，我一直在复制我在两个地方的验证：

1. 如果条件发生变化 当他们被检查 应用程序代码以及它们何时 在数据库中检查， 业务规则检查数据库 将节省一天。数据库 也允许我锁定各种 记录的方式比简单的方式更简单 我的应用程序代码，似乎 在这里这样做很自然。
2. 如果有的话 做一些批量数据 如果我路由，直接插入/更新数据库 通过我的所有这些操作 存储过程/函数 正在做业务规则 验证，我没有机会 即使我缺乏通过应用程序进行单输入而获得的保护，也会输入不良数据。
3. 虽然 只执行这些事情 数据库会产生同样的效果 看来，就实际数据而言 不恰当地把数据扔到了 数据库在第一次做好之前 努力验证它是否符合 约束和业务规则。

什么是正确的平衡？

Answer 1

您需要在数据层强制执行以确保数据完整性。这是你的最后一道防线，也就是数据库的工作，以帮助强制执行其数据的世界观。

也就是说，将垃圾数据扔到数据库进行验证是一种粗略的技术。通常，错误被设计为人类可读而不是机器可读，因此程序处理来自数据库的错误并使其从头部或尾部出来的效率低下。

存储过程是另一回事。在当天，存储过程是处理数据层等业务规则的方法。

但是今天，在现代应用程序服务器环境中，它们已成为一种更好的地方来放置这种逻辑。它们提供了多种访问和公开数据的方式（Web，Web服务，远程协议，API等）。此外，如果你的规则是CPU重（可能大多数不是），那么扩展应用服务器比数据库服务器更容易。

应用程序服务器中的大量功能为他们提供了超出数据库服务器所能做的灵活性，因此，当数据库服务器被降级为“愚蠢”时，大部分曾被推回到数据库的内容被撤出持久性”。

尽管如此，使用存储过程等确实存在性能优势，但现在这是一个调整问题，“问题变成”是否值得失去应用服务器功能以获得通过将其放入数据库服务器获得的收益“

通过app服务器，我不只是简单地谈论Java，而是.NET甚至PHP等。

Answer 2

如果必须始终强制执行规则，无论数据来自何处或如何更新，数据库都是必需的。记住数据库受直接查询影响许多记录或执行应用程序通常不会执行的操作的影响。当客户被另一个客户买断并且他们想要更改所有历史数据，将新税率应用于尚未处理的订单，修复一些不良数据输入时，这些就像修复一组记录。它们有时也受到其他不使用数据层的应用程序的影响。它们也可能受到通过ETL程序运行的导入的影响，这些程序也无法使用您的数据层。因此，如果必须遵循规则，则必须在数据库中。

如果规则仅适用于有关此特定输入页面如何工作的特殊情况，则需要在应用程序中。因此，如果销售经理只能通过其用户界面执行特定操作，则可以在应用程序中指定这些内容。

有些事情在两个地方都有帮助。例如，允许用户在与日期字段相关的输入框中放置非日期是愚蠢的。数据库中的数据类型仍应是datetime数据类型，但最好在发送之前检查其中的一些内容。

Answer 3

您的业务逻辑可以位于任一位置，但不应位于两者中。逻辑不应该重复，因为试图保持两者同步很容易出错。如果您将其放入模型中，您将希望所有数据访问都通过您的模型，包括批量更新。

将它放在数据库中与应用程序模型（这是我的头脑中的几个）之间存在权衡：

• 数据库可能比应用程序更难维护和更新
• 如果在应用程序层中分配负载
，则更容易
• 多个不同的dbs可能需要拆分业务规则（这可能是不可能的）