验证器是否重复业务逻辑？

Question

我知道可以使用验证器来检查应用程序的表示层中的数据输入（例如正则表达式，必填字段等），并显示消息和/或所需的标记图标。数据验证通常属于业务层。如何避免对我收集的数据进行两组验证？

编辑：我知道演示文稿验证很好，并且它会通知用户，并且它不是绝对可靠的。事实仍然是，不是吗，我在两个地方有效地检查了同样的事情？

Answer 1

是的，没有。

这取决于您的应用程序的体系结构。我们假设您正在构建一个n层应用程序，因为如今绝大多数应用程序都倾向于遵循该模型。

用户界面中的验证旨在向系统的最终用户提供即时反馈，以防止较低层中的功能在无效输入的情况下首先执行。例如，如果没有用户名和密码来尝试身份验证，您甚至不想尝试联系Active Directory服务器。此时的验证可以节省处理实例化对象，设置对象以及对服务器进行不必要的往返所需的处理时间，以便通过简单的数据检查来学习您可以轻松告诉的内容。

您的类库中的验证是另一回事。在这里，您要验证业务规则。虽然可以说用户界面中的验证和类库中的验证是相同的，但我倾向于不同意。业务规则验证往往要复杂得多。在这种情况下，您的规则可能会更加微妙，并且可能会检测到无法通过用户界面收集的内容。例如，您可以强制执行一条规则，该规则指出用户可以仅在已正确初始化所有类的属性之后执行方法，并且仅当用户是特定用户组的成员时才执行。或者，您可以指定只有在最近二十四小时内未修改对象时才可以修改该对象。或者，您可以简单地指定字符串值不能为null或为空。

但是，在我看来，设计合理的软件使用通用机制从UI和类库中强制执行DRY（如果可能）。在大多数情况下，这是可能的。 （在许多情况下，代码是如此微不足道，这是不值得的。）

Answer 2

我不认为客户端（表示层）验证是实际的，有用的验证;相反，它只是通知用户服务器端（业务层）验证将发现的任何错误。我认为它是一个用户界面组件，而不是一个实际的验证工具，因此，我认为这两者都不会违反DRY。

编辑：是的，你正在做同样的动作，但原因完全不同。如果您的唯一目标是严格遵守DRY，那么您不希望两者兼顾。但是，通过执行这两个操作，当您执行相同的操作时，该操作的结果将用于不同的目的（实际验证信息与通知用户问题），因此，执行相同的操作两次实际结果每次都有用的信息。

Answer 3

我认为在应用层进行良好的验证可以带来多重好处。 1.促进单元测试 2.您可以添加多个客户端，而无需担心数据一致性。

UI验证可用作为最终用户提供快速响应时间的工具。

Answer 4

每个验证层都有不同的用途。用户界面验证用于丢弃错误输入。业务逻辑验证用于基于业务规则执行验证。

对于UI验证，您可以使用ASP.NET框架中提供的RequiredFieldValidators和其他验证程序。对于业务验证，您可以创建验证对象的验证引擎。这可以通过使用自定义属性来完成。

这篇文章解释了如何使用自定义属性创建验证框架：

http://highoncoding.com/Articles/424_Creating_a_Domain_Object_Validation_Framework.aspx