关于BeanCopier的一些思考

标签: 基础技术 Bean 属性复制 | 发表时间:2016-01-24 22:00 | 作者:jaygo
出处:http://www.importnew.com

在做业务的时候,我们有时为了隔离变化,会将DAO查询出来的Entity,和对外提供的DTO隔离开来。大概90%的时候,它们的结构都是类似的,但是我们很不喜欢写很多冗长的b.setF1(a.getF1())这样的代码,于是我们需要BeanCopier来帮助我们。

在做业务的时候,我们有时为了隔离变化,会将DAO查询出来的Entity,和对外提供的DTO隔离开来。大概90%的时候,它们的结构都是类似的,但是我们很不喜欢写很多冗长的b.setF1(a.getF1())这样的代码,于是我们需要BeanCopier来帮助我们。

BeanCopier其实已经有很多开源版本,例如 DozerMapperApache BeanUtilsSpringJodd BeanUtils甚至是 Cglib都提供了这样的功能。在比较这些工具之前,我想先提提我对BeanCopier的一些要求。

1. 性能

BeanCopier是一个很常用的操作,如果是一个批量的请求,就更加明显了。使用效率太低的库不太划算,我对这些工具做了一个对比:Copy一个简单Bean 1,000,000次,计算总耗时(测试代码在 这里)。比较结果如下:

1,000,000 round
jdk set/get takes 17ms
cglib takes 117ms
jodd takes 5309ms
dozer mapper takes 2336ms
apche beanutils takes 6264ms

其中jdk的直接写set/get是最快的,所以在性能要求高的场景下倒是不妨自己写。另外这样写也是对 重构比较友好,这是其他几个工具都做不到的。

其次是用了字节码生成的cglib,然后将其他的库远远甩在后面。其他的库性能相差不大,大约1000次拷贝会消耗数毫秒时间,对于性能敏感的应用,特别是一些批量请求,消耗还是比较大的。

2. 内聚性

其实Bean Copy可以扩展到更一般的情况:我们需要对两个类似的Bean做转换,输入是一个Bean,输出是另外一个类似的Bean。这种逻辑里,除了简单的字段拷贝,可能也会有一些计算逻辑,甚至还会依赖一些外部数据源,而我们还希望最好把转换的逻辑都放在一起,同时也起到 规范业务的作用。

DozerMapper在这条路上走的很远。它通过XML/API/Annotation的方式,支持简单形式的转换、映射,从而更好的处理一些字段不一样的情况,用意就是一个Mapper搞定一切。例如下面的例子,可以将不同名称的字段进行映射。

<?xml version="1.0" encoding="UTF-8"?>
<mappings xmlns="http://dozer.sourceforge.net"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://dozer.sourceforge.net

http://dozer.sourceforge.net/schema/beanmapping.xsd">

  <mapping> 
    <class-a>org.dozer.vo.TestObject</class-a>
    <class-b>org.dozer.vo.TestObjectPrime</class-b>   
    <field>
      <a>one</a>
      <b>onePrime</b>
    </field>
  </mapping>  

  <mapping wildcard="false"> 
    <class-a>org.dozer.vo.TestObjectFoo</class-a>
    <class-b>org.dozer.vo.TestObjectFooPrime</class-b>   
      <field>
        <a>oneFoo</a>
        <b>oneFooPrime</b>
      </field>
  </mapping>  

</mappings>

但是,假设我们的场景不是需要整合很多项目,而是自己制定规范和数据模型,这时我们真的需要这样的转换么?我认为 一开始就应该把相同的字段给予相同的名字,这样无论是对于理解、后续维护都会方便很多。即使这种不同名的情况存在,我们也不应该提倡。所以花这么大的力气去做字段的映射,增加了复杂度,我认为并不划算。这个时候,我们需要的是 仅仅对同名字段进行拷贝,其他属性交由手动处理

至此,一个BeanCopier就大体成型了:

public class BeanCopier<F,T> {

private net.sf.cglib.beans.BeanCopier beanCopier;

protected net.sf.cglib.beans.BeanCopier getBeanCopier() {
    return beanCopier;
}

protected void init(){
    this.beanCopier = net.sf.cglib.beans.BeanCopier.create(sourceClass, targetClass, false);
}

private Class<T> targetClass;

private Class<F> sourceClass;

protected Class<T> getTargetClass() {
    return targetClass;
}

protected Class<F> getSourceClass() {
    return sourceClass;
}

public void setTargetClass(Class<T> targetClass) {
    this.targetClass = targetClass;
}

public void setSourceClass(Class<F> sourceClass) {
    this.sourceClass = sourceClass;
}

public T afterCopy(F source, T target){
    return target;
}

public T copy(F input) {
    try {
        T o = targetClass.newInstance();
        beanCopier.copy(input, o, null);
        return afterCopy(input, o);
    } catch (Exception e) {
        throw new RuntimeException("create object fail, class:" + targetClass.getName() + " ", e);
    }
}

@Override
public T apply(F input) {
    return copy(input);
}
}

 

另外,很多情况下,我们不止是对字段值进行拷贝,还会有一些数据转换的需要。例如:将Entity的瘦模型中关联的一些数据,从简单的数据库关联外键变为一个完整的Entity,最后再整合成一个DTO。

这种情况下,我们的BeanCopyier还需要一些外部数据。在Spring中,我们会希望它去依赖DAO或者外部Service之类的Bean。于是我们还可以用Spring来配置它。

@Service
public class A2BBeanCopier extends BeanCopier<A,B> {

    @PostConstruct
    public void init(){
        setSourceClass(A.class);
        setTargetClass(B.class);
        super.init();
    }

    @Override
    public B afterCopy(A source, B target) {
        target.setF5("aaa");
        //Call some service
        return target;
    }
}

最后,项目我放到了oscgit上: http://git.oschina.net/flashsword20/abc

可能感兴趣的文章

相关 [beancopier 思考] 推荐:

关于BeanCopier的一些思考

- - ImportNew
在做业务的时候,我们有时为了隔离变化,会将DAO查询出来的Entity,和对外提供的DTO隔离开来. 大概90%的时候,它们的结构都是类似的,但是我们很不喜欢写很多冗长的b.setF1(a.getF1())这样的代码,于是我们需要BeanCopier来帮助我们. 在做业务的时候,我们有时为了隔离变化,会将DAO查询出来的Entity,和对外提供的DTO隔离开来.

终极思考

- wei - 牛博国际
我的海淀剧院演讲门票放出后,八小时卖了四百多张,同事们说,日. 我淡淡地说,别这样,也许正是因为便宜才这么好卖嘛. 一转身我马上就打电话给老婆,操. 早知道就他妈把票价定高一点啦,真倒霉......干. 很大程度上,这可以解释两件事:1.为什么已婚事业男性的健康状况会相对好一些. 2.为什么在社会上受到尊重和认可的事业男性在老婆的眼里都是傻逼.

动车追尾的思考

- David Ruan - 扬韬
1、两列运行的动车追尾,绝对属于重特大责任事故. 雷电导致前车失灵,已经是责任事故了. 前车失灵,信号没有外发,又是责任事故. 调度体系没有发觉列车失灵,也是责任事故. 后车没有察知前车失灵,还是责任事故. 最后,后车发现问题,紧急制动系统有没有用也值得怀疑,因为后车司机据说是人工制动并殉职于岗位的.

重新思考电子书

- Alex - 爱范儿 · Beats of Bits
Hart,“古登堡计划”发起人,2011 年 9 月 6 日去世,享年 64 岁. 从 1971 年 Hart 制作第一本电子书,启动“古登堡计划”开始到 2011 年,Kindle、Nook 流行,正好经过 40 年. 如今电子书阅读器、电子书变得越来越流行,在北京的地铁上,你会经常看见低头拿着 Kindle、Nook、iPad、汉王的人们.

《系统思考》读后感

- 章明 - 所有文章 - UCD大社区
经别人推荐(都忘了是谁推荐的了~),买了这本《系统思考》,看完前几章,发现这是一本非常好的书. 全书的精华也都在前面几章,后面都是一些具体的案例分析. 为什么必须从整体研究系统. 将系统分块通畅破坏了你所试图研究的系统. 如果你破坏了系统内的连接,你就破坏了系统本身. 更奇妙的是,很多系统表现出他们的任何组成部分都不具备的特征.

Memcache架构新思考

- - ITeye博客
2011年初Marc Kwiatkowski通过Memecache@Facebook介绍了Facebook的Memcache架构,现在重新审视这个架构,仍有很多方面在业界保持先进性. 作为weibo内部数据处理量最大,对数据延迟最敏感的部门,基于本厂2年多来对mc的使用心得,我在本文总结对MC架构的一些新思考.

Google Reade关闭的思考

- - 猫星石 ~CafeNeko
关于google reader所引起的口诛笔伐已经看的足够多了,所以这里我并不想再去谈Google的这个决定正确与否. 我想说的是关于”后GR时代”的一些思考. 关于GR的好我已经听的太多,曾几何时我也是重度的GR脑残粉. 但是早在GR宣布准备关闭时,我一边看着GR里面永远也不会清空的条目,我就在想,我真的还是GR的脑残粉吗.

表单设计的思考

- - 腾讯ISUX - 社交用户体验设计 - Better Experience Through Design
我们几乎每天都会接触形形色色的表单,登录账号、填写信息以获取服务、发布内容等. 然而填写表单的过程往往不是特别愉悦的,我们需要消耗时间输入信息,点击提交,可能还需要等待审核;尤其是碰到较为复杂、流程长的表单,如果用户体验较差,很容易让人产生挫败感,在中途选择放弃. 那么,如何提高用户填写表单的效率,防止他们出错或中途流失,提升愉悦度及转化率呢.

谈CIO思考之重点

- - 人月神话的BLOG
在这里主要针对中大型企业有专门的IT部门和独立开发运维团队的情况,对于这种企业的CIO,核心的一些思考点在哪里,和常规软件企业又有哪些差异. 对于企业IT部门是成本中心,在开源节流上,利润中心的重要性和关注度还是远远高于成本中心,这也是很多企业IT部门往往不受重视的原因,CIO本身也没有太多的决策权,在本身没有太多独立开发能力时候更多仅仅是一个运维中心的角色.

推行TDD的思考

- - 简单文本
目前来看,推行TDD的障碍大约有如下几点:. 分析需求并进行任务分解的能力; 3. 将测试作为开发起点的开发习惯; 4. 开发人员的重构能力,包括如何识别坏味道和如何运用重构手法; 5. 单元测试的基础设施,尤其是测试数据准备;. 开发人员对于软件质量,常常偏重于软件的外部质量,体现在他们的工作效益上,就是被测试人员发现的缺陷数.