JavaWeb开发经验谈:业务行为相似DAO接口的统一封装与使用

简介: 以对mybatis-plus的封装使用为例,给出一个在适用业务场景下大幅降低代码信息熵的解决方案

一个典型的web应用中可能会有很多DAO接口(也被称作mapper,以下皆称mapper),在某些业务场景中,我们会对不同的mapper进行高度相似的业务操作,这种情况下如果仍然裸用mapper进行CRUD,就可能制造出大批高信息熵的代码,久而久之,难以维护.

例如在笔者之前所开发的项目,它是一个云产品监控系统,通过组合阿里云的blink、datahub、TableStore以及一些java微服务,实现了对几十种阿里云产品的数百个监控项的统一配置实时监控和按规则报警.

为了便于blink服务分监控项计算受监控实例的某项指标是否突破阈值,我们存储实例阈值配置的表结构被设计以实例ID作为唯一标识,横向扩展监控项的横表结构:

实例ID

监控项1

监控项2

监控项3

更多监控项...

实例1

55

66

77

88

实例2

更多实例...

并且,让每一种产品都对应一张阈值横表,便于维护,也避免了给不同产品的同名监控项起别名(比方说,ECS和RDS都有内存使用率这个监控项)维护的成本.

在这个场景中,负责报警配置的业务开发人员事实上并不需要关心每个监控项的具体业务含义,他可以对监控项作一个统一的抽象:

// 由于历史原因,我们的项目为每一个监控项都创建了对应的VO,// 这样很繁琐,但是对于分类维护监控项或在domain层次针对性地扩展某个监控项则是有利的// 如果你偏好贫血模型,那么可以尝试用一个CommonMonitorConfig描述所有publicabstractclassCommonMonitorConfig {
// 超阈值状态超过此时间,则进行报警StringkeepTime;
// 自上一次发送报警后的沉默周期StringsilenceTime;
// 此监控项是否启用报警BooleanisOpen;
// 监控项对应的字段名称StringmonitorName;
//  配置阈值Doublevalue;
//  产品类型,贫血模型需要此字段StringproductType;
//  充血模型可以定义此方法,让处于产品及的监控类例如EcsMonitorConfig实现此方法    abstractTypeEnumgetTypeEnum();
publicCommonMonitorConfig(){
// 如果使用充血模型,你可以分门别类的在构造方法中按类型初始化一些默认配置    }
}

前端可以根据此抽象制作操作报警配置的表单界面并提交报警配置数据.在约束好CommonMonitorConfig的monitorName与阈值配置实例类相应字段的映射关系后,后端接口中可以使用反射方便规整地将VO对象的相应值映射统一到对应的DO对象中.

当然,在真正实现丝滑流畅无污染的反射之前还需要作一点点合理封装.

以实例阈值配置的存储和查询为例,首先给所有产品的entity类定义一个公共父类,并提取公共业务字段到父类中,使得子类实体只存放阈值:

publicclassCommonInsAlarmRule {
@TableIdpublicLongid;
/*** 规则编码*/publicStringruleUUID;
/*** 实例ID*/publicStringinstanceId;
publicStringmoduleCode;
}

然后,写一个ConfigUtil维护一些静态映射关系并封装常用方法:

/*** k: 产品类别* v: 报警规则实体类*/publicstaticfinalMap<TypeEnum, Class<?extendsCommonInsAlarmRule>>insClassMap=newImmutableMap.Builder<CloudProductTypeEnum, Class<?extendsCommonInsAlarmRule>>()
            .put(ECS, EcsAlarmRule.class)
            .put(EIP, EipAlarmRule.class)
            .put(RDS, RdsAlarmRule.class)
// ....            .build();
// 比方说,从上面的字典中获取insType,然后将其实例化为被标记为CommonInsAlarmRule的具体子类对象publicstatic<P, SextendsP>PnewInstance(Class<S>insType) {
try {
returninsType.newInstance();
        } catch (InstantiationException|IllegalAccessExceptione) {
        }
    }
// 这个方法直接定义在TypeEnum这个枚举类里publicstaticTypeEnumfindEnumByNameIgnoreCase(StringdisplayName){
returnArrays.stream(TypeEnum .values()).filter(e->e.displayName.equalsIgnoreCase(displayName)).findFirst().orElse(null);
    }

同样地,在ConfigUtil中注入并初始话各个产品mapper对象(这里以MybatisPlus为例)的映射关系:

privatestaticMap<String, BaseMapper<?extendsCommonInsAlarmRule>>instanceAlarmRuleMapperMap;
privatefinalEcsAlarmRuleMapperecsAlarmRuleMapper;
privatefinalRdsAlarmRuleMapperrdsAlarmRuleMapper;
privatefinalEipAlarmRuleMappereipAlarmRuleMapper;
//.... @PostConstructvoidinit(){
instanceAlarmRuleMapperMap=newImmutableMap.Builder<TypeEnum, BaseMapper<?extendsCommonInsAlarmRule>>()
                .put(EcsAlarmRule.class.getName(), ecsAlarmRuleMapper)
                .put(EipAlarmRule.class.getName(), eipAlarmRuleMapper)
                .put(RdsAlarmRule.class.getName(), rdsAlarmRuleMapper)
// .....                .build();
}

为了更好地利用MybatisPlus的LambdaQueryWrapper静态字段缓存进行代码中相关SQL的静态检查,需要为CommonInsAlarmRule创建一个无需对应任何数据库表的形式化mapper:

importcom.baomidou.mybatisplus.core.mapper.BaseMapper;
importorg.springframework.stereotype.Repository;
@RepositorypublicinterfaceAbstractInsMapperextendsBaseMapper<CommonInsAlarmRule> {
}


最后,在ConfigUtil中封装增删查改的常用方法:

publicstatic<TextendsCommonInsAlarmRule>BaseMapper<T>getInsAlarmRuleMapperByInsType(TypeEnumproductType) {
Class<T>clazz= (Class<T>) insClassMap.get(productType);
return (BaseMapper<T>) instanceAlarmRuleMapperMap.get(clazz.getName());
    }
publicstaticList<CommonInsAlarmRule>selectList(CloudProductTypeEnumproductType, LambdaQueryWrapper<CommonInsAlarmRule>wrapper) {
returngetInsAlarmRuleMapperByInsType(productType).selectList(wrapper);
    }
publicstaticCommonInsAlarmRuleselectOne(CloudProductTypeEnumproductType, LambdaQueryWrapper<CommonInsAlarmRule>wrapper) {
returngetInsAlarmRuleMapperByInsType(productType).selectOne(wrapper);
    }
publicintinsertOne(CloudProductTypeEnumproductType, CommonInsAlarmRulerule){
returngetInsAlarmRuleMapperByInsType(productType).insert(rule);
    }

举个例子,下图是一段根据实例ID及产品类型查询指定实例的配置阈值的代码,可以明显看出,这段代码的信息熵会随着产品数量的增加而逐渐升高:

1.png

使用统一封装之后的接口来替代原先的这段代码,只需三行,且可在后续迭代中保持信息密度不变:

2.png

相关文章
|
4天前
|
JSON Java Apache
非常实用的Http应用框架,杜绝Java Http 接口对接繁琐编程
UniHttp 是一个声明式的 HTTP 接口对接框架,帮助开发者快速对接第三方 HTTP 接口。通过 @HttpApi 注解定义接口,使用 @GetHttpInterface 和 @PostHttpInterface 等注解配置请求方法和参数。支持自定义代理逻辑、全局请求参数、错误处理和连接池配置,提高代码的内聚性和可读性。
|
5天前
|
Java
java线程接口
Thread的构造方法创建对象的时候传入了Runnable接口的对象 ,Runnable接口对象重写run方法相当于指定线程任务,创建线程的时候绑定了该线程对象要干的任务。 Runnable的对象称之为:线程任务对象 不是线程对象 必须要交给Thread线程对象。 通过Thread的构造方法, 就可以把任务对象Runnable,绑定到Thread对象中, 将来执行start方法,就会自动执行Runable实现类对象中的run里面的内容。
18 1
|
11天前
|
Java 开发者
在Java多线程编程的世界里,Lock接口正逐渐成为高手们的首选,取代了传统的synchronized关键字
在Java多线程编程的世界里,Lock接口正逐渐成为高手们的首选,取代了传统的synchronized关键字
38 4
|
17天前
|
安全 Java
在 Java 中使用实现 Runnable 接口的方式创建线程
【10月更文挑战第22天】通过以上内容的介绍,相信你已经对在 Java 中如何使用实现 Runnable 接口的方式创建线程有了更深入的了解。在实际应用中,需要根据具体的需求和场景,合理选择线程创建方式,并注意线程安全、同步、通信等相关问题,以确保程序的正确性和稳定性。
|
15天前
|
Java
Java基础(13)抽象类、接口
本文介绍了Java面向对象编程中的抽象类和接口两个核心概念。抽象类不能被实例化,通常用于定义子类的通用方法和属性;接口则是完全抽象的类,允许声明一组方法但不实现它们。文章通过代码示例详细解析了抽象类和接口的定义及实现,并讨论了它们的区别和使用场景。
|
16天前
|
Java 测试技术 API
Java零基础-接口详解
【10月更文挑战第19天】Java零基础教学篇,手把手实践教学!
16 1
|
21天前
|
Java 开发者
在Java多线程编程中,创建线程的方法有两种:继承Thread类和实现Runnable接口
【10月更文挑战第20天】在Java多线程编程中,创建线程的方法有两种:继承Thread类和实现Runnable接口。本文揭示了这两种方式的微妙差异和潜在陷阱,帮助你更好地理解和选择适合项目需求的线程创建方式。
15 3
|
21天前
|
Java
在Java多线程编程中,实现Runnable接口通常优于继承Thread类
【10月更文挑战第20天】在Java多线程编程中,实现Runnable接口通常优于继承Thread类。原因包括:1) Java只支持单继承,实现接口不受此限制;2) Runnable接口便于代码复用和线程池管理;3) 分离任务与线程,提高灵活性。因此,实现Runnable接口是更佳选择。
29 2
|
21天前
|
Java
Java中多线程编程的基本概念和创建线程的两种主要方式:继承Thread类和实现Runnable接口
【10月更文挑战第20天】《JAVA多线程深度解析:线程的创建之路》介绍了Java中多线程编程的基本概念和创建线程的两种主要方式:继承Thread类和实现Runnable接口。文章详细讲解了每种方式的实现方法、优缺点及适用场景,帮助读者更好地理解和掌握多线程编程技术,为复杂任务的高效处理奠定基础。
27 2
|
21天前
|
Java 开发者
Java多线程初学者指南:介绍通过继承Thread类与实现Runnable接口两种方式创建线程的方法及其优缺点
【10月更文挑战第20天】Java多线程初学者指南:介绍通过继承Thread类与实现Runnable接口两种方式创建线程的方法及其优缺点,重点解析为何实现Runnable接口更具灵活性、资源共享及易于管理的优势。
27 1