我正在.net 3.5中使用linq to sql，并基于底层数据库构建了一些类。我现在面临这样一个决定：我是在类代码中验证数据，还是在数据库中验证数据？
不管怎样，我都能看到利弊。如果我在数据库中进行验证，则无论哪个应用程序正在使用数据库，都会进行验证。（我目前不认为任何其他应用程序会访问这个数据库，但谁知道呢。）
哦，这个类提供了一个更加健壮的编程环境来完成我的验证。当然，它允许我在用户界面处于用户可以更正问题的状态时捕获问题，而不是等待项目提交到数据库。linq to sql可以捕获列的数据类型，但是（afaik）不提供底层数据库中任何检查或默认约束的编程强制。
例如，实体的“last modified”属性：我可以在数据库中使用on-insert触发器更新它，也可以在类本身的propertychanged事件中进行更新（让类订阅自己的事件听起来很奇怪，但由于类位于定义为部分类的两个文件中，其中一个文件是由IDE自动生成的，这样做意味着我不必篡改自动生成的文件，所以如果我必须重新生成.dbml，它不会中断，或者当实体提交到数据库时，我可以在应用程序中执行。
我不想在数据库和类中重复验证。我喜欢类代码中健壮的验证环境。但我的纯粹主义者认为，即使另一个应用程序（我也不认为它会发生）使用数据库，在数据库中验证也能确保一致性。
其他人怎么看这个话题？
最佳答案
嗯，最好在多个层次上进行验证。我认为在ui层、业务逻辑层和数据库本身中执行不同类型的验证没有问题。
在我看来，理想的场景是ui层验证用户提交的数据是否存在恶意输入、非法值、regex模式匹配和必需字段。第二层将验证数据的类型，以及它是否将网格连接在一起以形成可以传播到数据存储的具体可更新对象。数据库将对所有操作施加基本约束，如您提到的约束。
此外，所需的验证级别将随着级别的降低而降低…从ui层的严格到数据库层的基本。
我相信有一条规则：“除非证明不是这样，否则所有的投入都是邪恶的。”
关于database - 验证:是在类中还是在数据库中？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/1093595/