3

在某些项目中,我发现需要在 Db 中创建一个虚拟记录,以便在不破坏 Db 约束的情况下保持业务逻辑继续进行。

到目前为止,我已经以两种方式看到了它的用法:

  • 通过添加像 IsDummy 这样的字段
  • 通过添加一个名为 ObjectType 的字段,它指向一个类型:Dummy

好的,它有助于实现需要实现的目标。

但是让我对此类解决方案感到警惕的是,有时您必须记住,应用程序中存在一些需要在某些进程中处理的虚拟记录。如果没有,您将面临一些问题,直到您意识到它们的存在或团队中的某个人告诉您“啊哈!您忘记了虚拟记录。您也应该这样做……

所以问题是: 创建虚拟记录以保持业务逻辑不变而不让 Db 抱怨是个好主意吗?如果是,防止开发人员跳过他们的存在的最佳做法是什么?如果没有,您将如何防止自己陷入最终只能选择创建虚拟记录的情况?

谢谢!

4

8 回答 8

6

使用虚拟记录不如获得正确的约束。

使用它们通常很容易,因为使用虚拟记录似乎是交付新功能的最快方式(有时可能是),但它们绝不是好的设计的一部分,因为它们隐藏了域逻辑和数据之间的差异模型。

于 2010-11-10T16:57:46.037 回答
5

仅当建模者无法轻松更改数据库定义时才需要虚拟记录,这意味着定义和/或数据模型非常糟糕。永远不应该在应用层中必须有特殊代码来处理数据库中的特殊情况的情况下结束。这是一个有保证的维护噩梦。

任何好的定义或模型都将允许轻松更改,而不会“影响现有代码”。

[在数据库中定义的]所有业务逻辑都应该使用 ANSI SQL 约束、检查和规则来实现。(当然,较低级别的结构已经通过域/数据类型等受到限制,但我不会将它们归类为“业务规则”。)我确保我最终不必实现虚拟对象,只需这样做。

如果不能做到这一点,那么建模者就缺乏知识和经验。或者更高级别的要求(例如规范化)已被打破,这给实施依赖于它们的约束带来了障碍;也意味着建模失败。

我从来不需要打破这样的约束,或者添加虚拟记录(而且我已经在大量的数据库上工作过)。当我重做其他人创建的数据库时,我已经删除了虚拟记录(和重复)。

于 2010-11-11T04:26:29.447 回答
4

我从来没有遇到过必须这样做。如果您需要这样做,那么您的数据结构有问题,并且会导致进一步的报告问题......

于 2010-11-10T16:59:32.170 回答
4

使用 Dummies 是愚蠢的。

一般来说,你应该致力于在没有它们的情况下让你的逻辑正确。我也看到它们使用过,但仅作为紧急解决方案。您的描述听起来太像将其作为标准做法。这将导致比它解决的问题更多的问题。

于 2010-11-10T17:01:32.577 回答
3

我可以看到添加“虚拟”记录的唯一原因是当您的应用程序和数据库设计严重错误时。

这绝对不是常见的做法。

如果您的业务逻辑依赖于现有的记录,那么您需要做以下两件事之一:确保在执行该逻辑之前创建了正确的记录;或者,更改逻辑以考虑丢失的信息。

于 2010-11-10T17:00:39.100 回答
2

我必须在这里带着普遍的感觉去反对虚拟记录。

将会发生的情况是,新开发人员不会知道它们,也不会编写处理它们的代码,或者删除表并忘记添加新的虚拟记录。

我在遗留数据库中体验过它们,并且看到了上述两种情况。

此外,它们存在的时间越长,就越难将它们取出,并且您必须编写更多的代码来考虑这些虚拟记录,如果您只是在没有它们的情况下进行原始设计,这些虚拟记录可能已经被删除。

于 2010-11-10T17:12:23.327 回答
2

正确的解决方案是更新您的业务逻辑。

引用您的扩展解释:

假设您有一个 Package 对象,并且您已经实现了一个业务逻辑,即无法创建没有任何内容的 Package。您创建了一些业务层规则并设计了具有相关约束的数据库。但是几年后,需要一个新功能并且要实现它,您必须能够创建一个没有内容的包。为了克服这个问题,您决定创建一个在 UI 上不可见但允许您创建一个空包的虚拟内容。

因此,一次没有内容的包是无效的,因此业务层强制在包对象中存在内容。那讲得通。现在,如果现实世界的场景发生了变化,那么现在需要有效的理由来创建没有内容的包对象,那么需要更改的是业务逻辑层。

几乎普遍地在任何地方使用“虚拟”任何东西都是一个坏主意,通常表明实施中存在问题。在这种情况下,您正在使用虚拟数据来允许“符合”业务层,该业务层不再准确地表示业务的现实世界约束。

如果没有内容的包是无效的,那么允许“遵守”业务层的虚拟数据是一种愚蠢的黑客行为。本质上,您编写了规则来保护您自己的系统,然后又如何试图规避您自己的保护。另一方面,如果没有内容的包是有效的,那么业务层不应该强制执行虚假约束。在这两种情况下,虚拟数据都无效。

于 2010-11-10T21:27:50.093 回答
2

我认为任何不太容易区分为“业务逻辑”的情况都是尝试考虑更好方法的原因。

您提到“指向类型:Dummy”的事实使我相信您正在使用某种 ORM 来处理数据访问。对于像 NHibernate 这样的 ORM 解决方案,一个非常好的检查点(尽管不是唯一的)是您的源代码非常明确地描述了驱动您的应用程序的数据结构。这不仅允许您在源代码控制下轻松管理您的数据访问,而且还允许在出现问题时更轻松地进行调试(让我们面对现实,这不是问题是否会发生,而是何时发生)。

当您引入某种“拐杖”(例如虚拟记录)时,您忽略了数据库的意义。数据库可以对您的数据强制执行规则,以消除对此类事物的需求。我建议您在使用这种技术之前先查看您的应用程序逻辑。想想你的开发伙伴或新员工。如果他们需要添加一个功能而忘记了你的小“虚拟记录”逻辑怎么办?

您在问题中提到自己感到忧虑。跟着你的直觉走。摆脱虚拟记录。

于 2010-11-10T17:01:19.610 回答