我是C＃和SQL的新手。但是在过去的几年里，在大学学习时，一个问题真的开始在我内心燃烧。这是：
在我看来，有两种非常通用的方法来处理输入验证（即检查所需字段，以及正确范围内的数据等）。
第一种，传统方式显示的方式是：开发UI后，以某种方式将其连接到数据库后端。在用户界面上，检查输入是否正确，例如空白文本框，数字范围，或确保选中了收音机或复选框等。
第二种，以及数据库开发中显示的方式是：在字段上设置检查约束，例如不允许空值，唯一值，甚至范围和必需字段。
我的困境是这样的。鉴于在C＃这样的现代语言中，您可以进行一般的执行处理，并且考虑到大多数数据库（如SQL Server）在处理有关提交全部或无提交的数据更改方面都建立了大联盟容错。像这样的细节，除了最简单的程序外，在这个级别上很难编程。
所以我的问题是，为什么不直接在数据库后端的表中构建所有需求。利用前面提到的容错功能，忘记编写if语句以确保输入正确的数据，而只是在没有提交数据时使用通用的catch all execption处理程序。
也许这就是它如何完成，如果是这样，我真的很想知道。如果没有，为什么？我的偏好是尽可能避免编写代码。在更新时，代码更少，调试更少，问题更少。因此，我倾向于采用让DB后端完成工作的方法。这通常是正确的做法。
我知道一般的执行处理在资源方面被认为是“昂贵的”。但是，一旦你通过5或10个if语句来处理不同的字段及其约束，那么只需做一个通用的execption处理程序就必须更加高效。整体而言，它似乎更容易理解。 （至少我这样做的方式）。
感谢您的帮助。
答案 0 :(得分：6)
好的，这就是为什么你在两个地方都需要它。
首先，数据的完整性应该是最重要的，数据可以直接在数据库表中更改（故意通过脚本来说更新百万价格或偶然更新，甚至是心怀不满或犯罪的员工试图破坏数据库或窃取数据公司）。因此，不顾一切地避免在数据库中直接使用约束，这会导致数据不良。
现在在用户界面级别，您希望防止用户浪费时间提交错误数据，并且您希望防止服务器和网络浪费时间尝试处理它，因此您在该级别编写检查。此外，如果您需要插入多个表并且不使用转换（您应该使用但我怀疑它发生的频率低于它应该发生的那样），您不希望数据处于不一致状态。此外，用户讨厌当你尝试插入并且它失败并且告诉你X是错的然后他们修复了X并且现在Y错了但是之前错了，这个过程只是没有达到Y之前。
答案 1 :(得分：5)
你做到了。
在数据库级别创建约束，并在客户端级别检查这些约束。
无论数据输入方式如何，DB上的验证都可确保数据库中没有无效数据。 客户端的验证改善了用户体验。
答案 2 :(得分：5)
您通常无法构建用于检入数据库的所有逻辑。同样没有充分验证用户输入是打开攻击的好方法。
在每种方法中编写lesss守卫代码的一种方法是“Code Contracts”是微软研究的产物。
所有输入都应在客户端和服务器端验证。总是
还有一个巨大的捕获，很难分辨出哪个字段出错了。所以你最终会在另一端编写很多字段爆炸代码。
答案 3 :(得分：3)
虽然我一般主张尽可能多地放入数据库（这意味着你可以对“原始”数据尽可能高度自信），但这并不总是可行的，即使有强大的约束和SQL中可用的触发器。
此外，存在可能随时间变化的高级“完整性”事物，并且在约束中始终具有时间动态条件是不现实的。即自2007年以来的所有人力资源记录必须具有非NULL生日，但之前的生存日期允许保持为NULL，但任何行都不能设置为NULL。
我的观点是你几乎不会把它全部放在数据库中。
将所有东西放在可以的位置，并将其他人放在系统的更高级别。数据库是任何系统中非常重要的一部分，但它不是唯一的部分。只要它的设计有助于保护其周边并能够提供可靠的服务并保证它所说的它将保证系统的其他部分可以依赖于他们的假设，那么这就是你可以要求的最多。
答案 4 :(得分：1)
除了这里所做的所有答案之外，就像UI控件改进了用户的drammaticaly UX，并且可以完全改变应用程序的“图像”，DB上的验证是为了正确地将数据插入到DB中，但是在客户端上必须完成正确插入客户端数据。
考虑一个独立企业应用程序的示例。一位客户在家工作，他在蒙古的笔记本上填写了20张深夜发票。他回来后的第二天，与他的办公室SAP服务器同步。如果只在同步数据期间才会弄清楚错误，你可以想象这种情况有多糟糕。
只是一个例子。我肯定会有很多其他人。
祝你好运。答案 5 :(得分：0)
2年后，我现在有了不少经验。我不会接受我的答案作为正确的答案，因为这里的人做得很好，我对他们的答案非常满意。但是我想补充一点另一个重要的考虑因素，即回顾我的经验并没有在这里突出显示。我也使用堆栈溢出作为参考，因为我进步，我总是发现自己回顾我的问题和答案，这是我想添加它的另一个原因。就像我未来的一个笔记。
在该公司工作期间，我被要求构建一个可以完成工作的应用程序。有了这个，我还必须构建数据库的一部分。当我在公司结束时，我了解到他们正在编写另一个使用我的数据库的应用程序。实际上，我的观点是，正如许多人所指出的那样，数据是最重要的，你不知道当你离开时它将如何被访问。
我还了解到有3个地方需要验证数据：
还有另外一个担忧。随着平板电脑和智能手机等新技术的出现。这是另一个必须实施验证的地方。第四次相同的规则（除非它是一个网络应用程序）。
我后来才了解到，在MVC之前，我们有CGI表格，这些表格与通过网络处理数据有关（我谦卑地承认硬件方面的无知）但是从我解释的内容看来甚至可能有第五名做验证（虽然我对这完全错误持开放态度。）
我认为计算机科学的下一位大师如果能找到一种方法将所有验证和验证抽象到一个地方，那么他就会为自己命名，这样就不必在一堆地方改变这些规则。
最坏的情况：
如果：
总共有10多个地方没有太多夸张，还有其他操作系统。
即使是一个简单的年龄范围，这也会变得混乱，但如果他们带来一些新的电子邮件格式或其他复杂的验证，或者您必须更改一堆验证规则。现在你必须在至少3或4个地方修改它们本身就是坏的。
与此相关的主要问题是，您正在修改已投入，测试并经常证明可以正常运行并投放市场的大量代码和基础架构......
随着客户端数量的增长，修改经过良好测试的代码，不可能是一件好事。我认为这将是未来的一个主要问题。我想知道是否会有一个设计模式或最佳实践来解决它。如果有人知道，请告诉我。