java~接口的共享实体使用Map后更灵活

微服务时代的实体设计

在一个微服务时代,一个实体参数或者返回值,它可能是多服务之前共享的,而这个重复的实体你需要拷贝多份,这是违背DRP原则的,所以我们需要找一种更友好的方式来代替它,它就是Map,我们把实体的属性都映射成Map这种k、v的形式即可解耦!

B服务不需要处理A服务的实体

如果只是接受实体,然后把它传递给C服务,这时,你直接把它设计成Map即可

public class ADto:HashMap<String,Object>{}

B服务需要加工,过滤A服务的实体

如果B服务拿到A服务的实体后,需要对某些字段进行处理,那我们需要把这些字段抽象出来,把它的get方法公开,在程序的其它地方使用,而不需要把所有字段都复制过来,这也是解耦的一种体现!

/**
 * A计算模板.
 */
public class ATemplate extends HashMap<String, Object> {

  public Boolean getAllowBuildAccount() {
    return Boolean.valueOf(this.get("allowBuildAccount").toString());
  }


  public Boolean getAllowMakeAccount() {
    return Boolean.valueOf(this.get("allowMakeAccount").toString());
  }
}

在程序里,你可以使用这两个公司的方法

 List<ValidateResult> validateResultsList =
        accountsValidate(currentClientAccount, false, o -> o.getAllowMakeAccount()); //使用predicate里过滤它的字段

思路模型

graph TD b(a服务)-->a(HashMap) a-->c(b服务) a1(HashMap)-->Entity1 a1-->Entity2

个人认为:这种设计非常巧妙,当然会有一些装箱和拆箱的操作,但与程序扩展性相比,简直可以忽略!

posted @ 2018-07-18 12:08 张占岭 阅读(...) 评论(...) 编辑 收藏