业务代码与通用代码分离案例

业务代码与通用代码分离案例

背景

1.关联查询后返回结果数据

​ 由于微服务化，每个服务都具有独立的业务(数据)，那么如果我们要查询一个商品列表，商品表中有用户id，但没有用户姓名，因为商品服务和用户服务是两个单独的服务，两者的数据不是存在一个库里（不能使用关联查询），所以我们需要在返回商品列表处，对其进行遍历，然后根据用户id去查询用户的接口，拿到用户名称后，设置给商品列表返回。

2.对结果数据进行解密

​ 需求是返回用户列表，返回列表对象中的地址需要进行解密操作(因为地址在数据库中存的是密文)，所以需要在返回用户列表处，对其进行遍历，然后用地址去调解密接口，返回解密明文后，设置到用户列表中返回。

分析

​ 以上两种场景，有一个共同点：都需要对结果数据进行某种处理（例如关联查询、解密操作），如果把这类代码直接写到原来的业务代码里，则违背了单一职责原则(案例一：既要查询商品信息又要查询用户信息；案例二：既要查询用户信息，还要查询解密接口)，且还违背了开闭原则（案例二：例如原来的代码是不要求解密的，现在产品又要求需要对地址进行解密，如果直接在业务代码里修改，那么就违背了开闭原则，ps.开闭原则：对扩展开放、对修改关闭）。

​

结论

​ 我们需要把业务代码和非业务代码(通用代码)分离，可以使用动态代理设计模式AOP，通过环绕对其结果进行处理，但仅通过AOP技术是不够的，因为获取到其结果后，你不知道需要对哪个字段处理，这时候就需要注解技术了(what？不知道什么是注解？简单一句话理解就是：计算机可以读懂的代码注释)。把注解打在需要处理的字段上，并通过注解上备注，我们可以在处理结果的时候，再通过反射技术就可以获取到注解字段和注解上的所有备注信息。

​ 基于以上AOP+注解+反射，我们就可以实现一种业务代码和通用代码分离的封装逻辑。

实践

1.确定切入点(AOP)

如下方法，需要对返回的列表中user对象的address进行解密后再返回。则我们需要对其方法进行切面处理。

@RequestMapping(value = "/list")
public List<User> getUserList(){
   
    List<User> users=this.queryList();
    return users;
}

a.创建切面注解

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface SecretField {
   
}

b.基于注解的实现

@Aspect
@Component
public class SecretFieldAspect {
   

    @Autowired
    private SecretUtil secretUtil;

    //这里环绕用的是注解的方式，即注解打在哪里，就会进行切面处理方法
    @Around("@annotation(com.example.demo0719.SecretField)")
    public Object secretFieldValue(ProceedingJoinPoint pjp) throws Throwable {
   
        Object obj = pjp.proceed();
      	//加密处理,封装在了一个方法里
        secretUtil.decodeObj(obj);
        return obj;
    }

}

c.注解打在需要加密的方法上

//@SecretField,其注解即表示该方法会进入SecretFieldAspect的切面方法,因为在@Around处已经声明了。
@SecretField  
@RequestMapping(value = "/list")
public List<User> getUserList(){
   
    List<User> users=this