pen*_*ake 3 .net c# oop database-design dummy-data
在某些项目中,我看到需要在Db中创建虚拟记录,以便在不破坏Db约束的情况下保持业务逻辑继续运行.
到目前为止,我已经看到它的用法有两种:
好的,它有助于实现需要的目标.
但是,让我对这些解决方案保持警觉的原因有时您必须记住,应用程序中存在一些需要在某些进程中处理的虚拟记录.如果没有,你会遇到一些问题,直到你意识到它们的存在,或者直到团队中的某个人告诉你" 啊哈!你已经忘记了虚拟记录.你也应该...... "
所以问题是: 创建虚拟记录以保持业务逻辑不是让Db抱怨是不是一个好主意？如果是,那么阻止开发人员逃避存在的最佳做法是什么？如果没有,你做了什么来防止自己陷入最终只能创建虚拟记录的情况？
谢谢!
使用虚拟记录不如正确的约束.
通常有使用它们的诱惑,因为使用虚拟记录看起来像是提供新功能的最快方式(有时可能是这样),但它们从来都不是优秀设计的一部分,因为它们隐藏了域逻辑和数据之间的差异模型.
只有当建模者无法轻易更改数据库定义时才需要虚拟记录,这意味着定义和/或数据模型非常糟糕.在应用层中必须有特殊代码来处理数据库中的特殊情况时,应该永远不会结束这种情况.这是一个有保障的维护噩梦.
任何好的定义或模型都可以轻松地进行更改,而不会"影响现有代码".
应使用ANSI SQL约束,检查和规则实现所有业务逻辑[在数据库中定义].(当然,较低级别的结构已经通过域/数据类型等进行了约束,但我不会将它们归类为"业务规则".)我确保我最终不必实现虚拟变量,只需这样做即可.
如果无法做到,那么建模师缺乏知识和经验.或者更高级别的要求,例如规范化,已被打破,这对实施依赖于它们的约束提出了障碍; 也意味着建模者失败了.
我从来没有需要打破这样的约束,或添加虚拟记录(我已经在很多数据库上工作).当我重新编写其他人创建的数据库时,我删除了虚拟记录(和重复记录).
| 归档时间： |
|
| 查看次数： |
713 次 |
| 最近记录： |