设计模式在参数校验中的使用

最新推荐文章于 2024-07-27 10:37:10 发布

原创

最新推荐文章于 2024-07-27 10:37:10 发布 · 1.3k 阅读

10 ·

CC 4.0 BY-SA版权

文章标签：

#设计模式 #java #开发语言

本文通过一个具体的场景——动态数据库表的参数校验，探讨了如何运用设计模式来改善代码结构。利用注解+Aop切面进行校验处理，通过代理模式减少Controller和服务层的校验代码。同时，采用责任链模式，通过工厂初始化校验处理器，并按顺序执行校验。每个处理器实现特定的校验逻辑，实现了代码的解耦和可扩展性。

设计模式在参数校验中的使用

设计模式在我们项目代码中无处不在，但是我们知道这些设计模式的名词，但是使用它们确实异常地困难，下面参考一位大佬的博客，下面是他的博客地址，从一个特定的需求场景出发，谈谈设计模式应该如何在该场景下使用？？
大佬的博客链接

需求：

我们对于动态数据库表的校验，例如它新建时一些字段的非空校验；编辑时一些字段是否可编辑校验；一些字段的类型校验等等…此时，我们针对不同情况需要进行不同校验规则的校验，有的时候可能还需要多重校验叠加等情况，在这种背景下，使用设计模式进行业务拆解设计能够起到很大的作用和效果
以上需求可以大致如下图所示：
在这里插入图片描述
首先，我们对于校验来说，肯定不能叫繁重的校验代码在我们的Controoler层或者Service层进行编写，这样极大地增加了代码的繁重性和冗余，首先想到的就是利用代理帮我们进行校验，即通过注解+Aop切面类进行校验处理：

注解类：ParamCheck

@Target(ElementType.METHOD)   //作用在方法上
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ParamCheck {
   
   

    /**
     * 参数为枚举数组类型：因为校验规则可能是一些、多个规则的叠加
     * @return
     */
    FieldCheckEum[] value() default {
   
   };

}

枚举类：FieldCheckEum

@Getter
@AllArgsConstructor
public enum FieldCheckEum {
   
   

    CHECK_FIELD_EXIST(0,"存在校验"),

    CHECK_FILED_NULL(1,"非空校验"),

    CHECK_FILED_SEARCH(2,"搜索校验"),

    CHECK_FILED_EDIT(3,"编辑校验"),

    CHECK_FILED_IMPORT(4,"导入校验"),

    CHECK_FILED_SORT(5,"排序校验"),

    CHECK_FILED_TYPE(6,"类型校验");

    private Integer code;
    private String value;
}

切面类：ParamCheckAspect

@Aspect
@Component
@Slf4j
public class ParamCheckAspect

最低0.47元/天解锁文章