java – 验证逻辑应该在哪里？

发布时间：2020-12-14 05:37:59 所属栏目：Java 来源：网络整理

导读：题如何最好地管理需要复杂验证逻辑的对象图的构造？我想保留依赖注入,无可否认的构造函数的可测性原因. 可测性对我来说非常重要,你建议如何维护代码的这个属性？背景我有一个简单的java对象,它管理一些业务数据的结构： class Pojo{ protected final Stri

题

如何最好地管理需要复杂验证逻辑的对象图的构造？我想保留依赖注入,无可否认的构造函数的可测性原因.

可测性对我来说非常重要,你建议如何维护代码的这个属性？

背景

我有一个简单的java对象,它管理一些业务数据的结构：

class Pojo
{
    protected final String p;

    public Pojo(String p) {
        this.p = p;
    }
}

我想确保p是有效的格式,因为没有这种保证,这个业务对象真的没有意义;如果p是废话,它不应该被创建.然而,验证p是不平凡的.

抓住

真的需要复杂的验证逻辑,逻辑应该是完全可以测试的,所以我有一个单独的类中的逻辑：

final class BusinessLogic() implements Validator<String>
{
    public String validate(String p) throws InvalidFoo,InvalidBar {
        ...
    }
}

可能重复的问题

> Where Should Validation Logic Be Implemented? – 接受的答案对我来说是不可穿透的.我读到“在类的本地环境中运行”作为重言式,验证规则如何运行在除了“本地环境”之外的其他任何内容中？点2我没有想到,所以我不能评论.
> Where To Provide Logic Rules for Validation? – 两个答案都表明我的客户/数据提供者的责任原则上是我所喜欢的.但是,在我的情况下,客户端可能不是数据的发起者,无法验证.
> Where To Keep Validation Logic? – 建议的验证可以由模型所有,但是我发现这种方法不太适合测试.具体来说,对于每个单元测试,即使我正在测试模型的其他部分,我也需要关心所有的验证逻辑 – 我无法通过遵循建议的方法完全隔离我想要测试的内容.

我的想法到目前为止

虽然以下构造函数公开地声明了Pojo的依赖关系,并保留了它的简单可测性,但它是完全不安全的.这里没有什么可以防止客户端提供验证器,声称每个输入都是可以接受的！

public Pojo(Validator businessLogic,String p) throws InvalidFoo,InvalidBar {
    this.p = businessLogic.validate(p);
}

所以,我限制构造函数的可视性,我提供一个工厂方法,确保验证然后构造：

@VisibleForTesting
Pojo(String p) {
    this.p = p;
}

public static Pojo createPojo(String p) throws InvalidFoo,InvalidBar {
    Validator businessLogic = new BusinessLogic();
    businessLogic.validate(p);
    return new Pojo(p);
}

现在我可以将createPojo重构为一个工厂类,这将恢复Pojo的“单一责任”,并简化了工厂逻辑的测试,更不用说在每个新Pojo上不再浪费创建新的(无状态)BusinessLogic的性能优势.

我的直觉是我应该停下来,要求外界的意见.我在正确的轨道上吗？

解决方法

下面的一些回应要素…
让我知道是否有意义/回答你的问题.

简介：我认为您的系统可以是一个简单的库,一个多层次的应用程序或一个复杂的分布式系统,实际上并没有太多的区别,当涉及到验证：

>客户端：远程客户端(例如HTTP客户端)或只是另一个类调用您的库.
>服务：一个远程服务(例如REST服务)或者你暴露的API.

在哪里验证？

您通常要验证输入参数：

>在客户端,在将参数传递给服务之前,确保早期对象将有效下来.如果是远程服务,或者在生成参数和创建对象之间存在复杂的流程,则这是特别需要的.
>在服务端：

>在类级别,在您的构造函数中,以确保您创建有效的对象;
>在子系统级别,即管理这些对象的层(例如,DAL持久化您的Pojos);
>在您的服务的边界,例如您的库或您的控制器的facade或外部API(如MVC中,例如REST端点,Spring控制器等).

如何验证？

假设以上,因为您可能必须在多个地方重用您的验证逻辑,所以在utility class中提取它可能是个好主意.这样：

>你不要复制它(DRY！);
您确定系统的每一层都将以相同的方式进行验证;
>你可以轻松地单独测试这个逻辑(因为它是无状态的).

更具体地说,您至少会在构造函数中调用此逻辑,以强制对象的有效性(考虑将有效的依赖关系作为Pojo方法中的算法的先决条件)：

实用类：

public final class PojoValidator() {
    private PojoValidator() {
        // Pure utility class,do NOT instantiate.
    }

    public static String validateFoo(final String foo) {
        // Validate the provided foo here.
        // Validation logic can throw:
        // - checked exceptions if you can/want to recover from an invalid foo,// - unchecked exceptions if you consider these as runtime exceptions and can't really recover (less clutering of your API).
        return foo;
    }

    public static Bar validateBar(final Bar bar) {
        // Same as above...
        // Can itself call other validators.
        return bar;
    }
}

Pojo类：
请注意静态import语句以提高可读性.

import static PojoValidator.validateFoo;
import static PojoValidator.validateBar;

class Pojo {
    private final String foo;
    private final Bar bar;

    public Pojo(final String foo,final Bar bar) {
        validateFoo(foo);
        validateBar(bar);
        this.foo = foo;
        this.bar = bar;
    }
}

如何测试我的Pojo？

>您应该添加创建单元测试,以确保在构建时调用验证逻辑(以避免回归,因为人们可以通过删除X,Y,Z原因的此验证逻辑“稍后”简化“构造函数).
>如果它们很简单,可以内联创建依赖项,因为它使您的测试更易于阅读,因为您使用的所有内容都是本地的(较少的滚动,较小的心理尺度等)
>但是,如果您的Pojo依赖关系的设置复杂/冗长,以至于测试不再可读,则可以在@Before / setUp方法中考虑该设置,以便单元测试测试Pojo的逻辑真的专注于验证你的Pojo行为.

无论如何,我同意Jeff Storey：

>用有效参数编写测试,
>没有验证的构造函数只是为了您的测试.当您混合生产和测试代码时,它确实是一种代码气味,并且肯定会被某些人无意中使用,包括您的服务的稳定性.

最后,将您的测试视为代码示例,示例或可执行规范：您不想通过以下方式给出令人困惑的示例：

>注入无效参数;
>注入验证器,这将使您的API混乱/读取“奇怪”.

如果Pojo需要非常复杂的依赖关系呢？

[如果是这种情况,请告诉我们]

生产代码：
您可以尝试在工厂中隐藏这种复杂性.

测试代码：
或者：

>如上所述,以不同的方法考虑这一点;要么
>使用你的工厂;要么
>使用模拟参数,并配置它们,以便它们验证您的测试通过的要求.

编辑：关于安全性方面的输入验证的几个链接,这也可以是有用的：

> OWASP’s Input Validation Cheat Sheet
> OWASP’s wikipage about Data Validation

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!