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

Question

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

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

Answer 1

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

编辑：是的，您正在执行相同的操作，但出于完全不同的原因。如果您的唯一目标是严格遵守 DRY，那么您不想两者都做。但是，通过同时执行这两项操作，虽然您可能正在执行相同的操作，但该操作的结果用于不同的目的（实际上是验证信息与通知用户存在问题），因此，执行相同的操作两次实际上会产生结果每次都提供有用的信息。

Answer 2

是的,不.

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

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

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

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