70

作为一名软件工程师，我强烈倾向于在应用层编写业务逻辑，而通常只依赖数据库进行 CRUD（创建检索更新和删除）操作。另一方面，我遇到过大量业务逻辑写在存储过程中的应用程序（通常是较旧的应用程序），因此有些人更喜欢在数据库层中编写业务逻辑。

对于拥有和/或喜欢在存储过程中编写/编写业务逻辑的人，您使用此方法的原因是什么？

4

16 回答 16

44

我尝试将我在数据库中的业务逻辑严格限制为仅需要进行大量查询和更新才能执行单个应用程序操作的过程。有些人可能会争辩说，即使这样也应该在应用程序中，但如果可以的话，我喜欢保持 IO 的关闭。

数据库非常适合 CRUD，但如果它们因逻辑而变得臃肿：

  1. 逻辑在哪里变得混乱，
  2. 通常，数据库是一个孤岛，水平扩展不如应用服务器好。
  3. t_sql/PLsql 本质上难以阅读和程序化
  4. 您将丧失 OOAD 的所有好处。
于 2009-09-24T19:25:14.860 回答
32

尽可能将您的业务逻辑保持在最可测试和可调试的环境中。在其他人的现有答案中将业务逻辑存储在数据库中是有一些正当理由的，但它们几乎总是远远超过这一点。

于 2012-06-27T03:21:50.440 回答
21

将业务逻辑限制在应用层是短视的。经验丰富的专业数据库设计师很少允许在他们的系统上使用它。数据库需要有约束和触发器以及存储过程来帮助定义来自任何来源的数据将如何进入它。

如果数据库要保持其完整性并确保所有新数据源或数据更改都遵循规则，那么数据库就是放置所需逻辑的地方。把它放在应用层是一场等待发生的数据噩梦。数据库不仅仅从一个应用程序中获取信息。应用程序中的业务逻辑经常被导入无意中绕过（假设您有一个新客户希望将他们的旧历史数据导入您的系统或大量目标记录，没有人会通过接口输入一百万个可能的目标，它会在导入时发生。）它也被通过查询窗口所做的更改绕过以修复一次性问题（例如将所有产品的价格提高 10%）。如果您有应该应用于数据更改的应用层逻辑，不会的。现在放到应用层也可以了，没有意义把坏数据发到数据库，浪费网络带宽，但是不放到数据库迟早会造成数据问题。

将所有这些都保存在数据库中的另一个原因与用户进行欺诈的可能性有关。如果您将所有逻辑都放在应用程序层，那么您必须授予用户直接访问表的权限。如果您将所有逻辑封装在存储过程中，它们可以被限制为仅执行存储过程允许的事情，而不是其他任何事情。我不会考虑允许用户以任何形式访问存储财务记录或个人信息（例如健康记录）的数据库，因为我不允许除了几个 dbas 之外的任何人以任何形式或形式直接访问生产记录. 欺诈行为比许多开发人员意识到的要多，而且几乎没有人在他们的设计中考虑过这种可能性。

如果您需要导入大量数据，通过数据访问层可能会减慢导入速度，因为它没有利用数据库旨在处理的基于集合的操作。

于 2009-09-24T20:15:25.780 回答
16

您对“业务逻辑”一词的使用相当模糊。

它可以被解释为意味着包括对数据的约束（又名“业务规则”）的强制执行。执行这些明确地属于 dbms 期间。

它也可以解释为包括“如果有新客户到达，那么我们会在一周内向他发送一封欢迎信”之类的内容。试图在数据层中推送这样的东西可能是一个很大的错误。在这种情况下，“创建新欢迎信”的驱动程序可能应该是也触发新客户行插入的应用程序。想象一下每一个新的数据库行插入都会触发一封新的欢迎信，然后我们突然接管了另一家公司，我们必须将那家公司的客户整合到我们自己的数据库中……哎呀。

于 2009-09-25T14:14:32.730 回答
12

在适当的情况下，我们在 DB 层进行了大量处理。有很多操作您不希望将大型数据集拉回应用程序层进行分析。这对我们来说也是一个更容易的部署——单点与在所有安装点更新应用程序。但是很大程度上取决于您的应用程序及其功能；这里没有一个好的答案。

于 2009-09-24T19:36:15.960 回答
7

在几个场合，我将“逻辑”放在存储过程中，因为 CRUD 可能发生在不止一个地方。通过“逻辑”，我不得不说这不是真正的业务逻辑，而是更多的“完整性逻辑”。可能是一样的 - 如果某些内容以某种方式被删除或更新，则可能需要进行一些清理，并且如果删除或更新可能来自多个具有不同代码库的工具，那么将其放入他们的 proc 中是有意义的全部使用。

此外，有时“业务逻辑线”非常模糊。以报告为例——它们可能依赖于存储过程或封装“智能”关于模式对业务意味着什么的视图。您是否经常看到基于列值或其他标准“做事”的 CASE 语句等？可以解释为业务逻辑，但它可能确实属于可以优化的数据库等。

于 2009-09-24T19:17:48.540 回答
7

我想说，如果“业务逻辑”是指应用程序流、用户控制、定时操作以及通常的“做生意的东西”，那么它应该在应用程序层中。但是，如果这意味着确保无论您如何挖掘数据，它始终是有意义的，并且是一个明智的、非自冲突的整体，那么执行这些规则的检查将毫无疑问地进入数据库。总是有很多方法可以将数据推送到数据库中并在其出现后对其进行操作。并非所有这些方式都内置了“业务逻辑”。例如，在凌晨 3 点的支持电话中，您会发现通过 DOS 窗口进入数据库的 SQL 会话非常自由！如果数据库中没有确保所有数据更改都有意义的逻辑，那么您可以肯定的是，随着时间的推移，数据会变得非常非常糟糕。

于 2012-07-30T13:56:35.823 回答
5

将业务逻辑放入数据库的两个很好的理由是：

  • 它可以保护您的逻辑和数据免受可能访问未实现类似逻辑的数据库的其他应用程序的影响。
  • 数据库设计通常比应用程序层更长寿，并且当您在客户端迁移到新技术时，它减少了必要的工作。
于 2009-09-24T19:18:22.830 回答
5

您经常会在数据库层找到业务逻辑，因为它通常可以更快地进行更改和部署。我认为通常最好的意图不是把逻辑放在那里，而是因为易于部署，它最终放在那里。

于 2009-09-24T19:19:07.370 回答
4

我在一家金融类公司工作，该公司的某些规则由各州实施，这些规则及其计算几乎每天都会发生变化，如果不是每周肯定会发生变化。在这种情况下，将处理计算的部分逻辑移至数据库更有意义；无需重新编译和重新分发应用程序即可测试和应用更改，而这不可能每天都在不中断业务的情况下进行。存储过程经过测试、批准、应用，最终用户也不明智。随着迁移到基于 Web 的应用程序，对将逻辑迁移到数据库的依赖减少了，但仍然存在。甚至网络应用程序（取决于语言）也必须编译并发布到可能导致停机的站点。

于 2011-05-18T14:35:42.810 回答
3

有时业务逻辑太慢而无法在应用层上运行。在客户端功率和带宽更加有限的旧系统上尤其如此。

于 2009-09-24T19:16:01.480 回答
3

使用数据库来完成工作的主要原因是你有一个单点控制。通常，应用程序开发人员在应用程序的不同部分重复使用或重写代码片段。即使假设这些都以完全相同的方式工作（这是值得怀疑的），当业务逻辑发生变化时，需要对应用程序进行审查、重新编码、重新编译。除非参数发生变化，否则如果业务逻辑仅存储在数据库中，则不需要这样做。

于 2009-09-24T19:21:31.907 回答
3

我的偏好是将任何复杂的业务逻辑排除在数据库之外，仅出于维护目的。如果我在凌晨 2 点接到电话，我宁愿调试我的应用程序代码，也不愿尝试单步调试数据库脚本。

于 2009-09-24T19:21:43.837 回答
3

过去我将 BL 放在存储过程中的主要原因是数据库中的事务更容易。

如果您的应用很难部署并且您没有应用服务器，那么更改存储过程中的 BL 是部署更改的最有效方法。

于 2009-09-24T19:24:07.030 回答
2

我认为特别是对于我正在处理的业务逻辑巨大的旧应用程序（银行），在应用程序层执行所有这些业务逻辑几乎是不可能的，而且当我们将这些逻辑放在应用程序层时，它的性能受到很大影响获取到数据库的次数更多，会导致更多的资源利用率（如果在 java 层完成，则更多的 java 对象）和网络问题并忘记 abt 性能。

于 2010-07-23T11:46:49.997 回答
2

我在一个团队中建立和维护一个相当大的金融系统，我发现没有办法将逻辑放入应用程序层以执行影响或从成千上万条记录中获取约束的操作。

除了性能问题，如果发生错误，纠正存储过程比调试应用程序、修复、重新编译、重新部署代码要快得多，停机时间更长

于 2012-12-26T08:08:13.533 回答