代码之家 › 专栏 › 技术社区 › Mayo

存储库中的业务规则?

business-logic repository sql

6

Mayo · 技术社区 · 15 年前

让我们假设一个应用程序在模型/表示层中具有所有必要的业务规则,并且它们工作正常。我的问题是是否有多余的业务规则(即 两个日期的跨度不能与任何其他现有跨度重叠 )应该在像SQL Server这样的存储库中使用。

是否有必要/有益于在SQL Server中添加强制执行此规则的约束?一方面,它可以防止任何人(包括DBA)在绕过应用程序时不小心违反业务规则。此外,我们已经通过主键和外键在存储库中提供了一些形式的业务规则。另一方面,重复的规则需要额外的时间来开发和维护。

这个问题跨越了许多不同的技术,所以我有意保持标签的通用性。

5 回复 | 直到 15 年前

1

6

HLGEM 15 年前

如果您关心您的数据,您将把所需的规则放在那里,而不是放在其他地方。数据受应用之外的许多地方的影响。将规则只放在业务层中是一件轻而易举的事情,并且会导致严重的数据完整性问题。有关数据的规则属于数据库。

2

5

Eric J. 15 年前

您通常会发现手工在多个地方维护业务规则非常困难。

我已经很好地利用了一些项目上的代码生成来从需求模型生成一些类型的规则。例如,我可能要求“名字不能超过50个字符”。我以一种结构化的方式在UML中建模该需求,然后生成UI代码,将输入限制为50个字符,业务逻辑强制执行相同的限制(永远不要信任UI!)和DDL/ORM映射文件,以指定数据库中的列宽。

同样的想法可以扩展到对更复杂的规则建模,并在应用程序的每一层生成适当的强制代码。

3

5

gbn 15 年前

业务规则还是数据完整性规则?

我的经验(主要是大公司,我们不是在这里讨论软件公司或业余爱好商店)是,您的数据库将比应用程序长。最终会有其他应用程序与之对话。如果数据库中没有适当的规则(无论是什么类型的规则),某个人就会破坏它。

4

1

dacracot 15 年前

你自己说的…是什么在后门执行业务规则(即DBA探测数据)。如果你担心这会发生,那就付出代价。如果没有,那就把它关掉,这样其他地方执行的规则就不会多余。

5

0

OMG Ponies 15 年前

取决于您的应用程序-如果逻辑打算与数据库无关,请将其保留在应用程序代码中。否则,业务规则更适合于数据库。