Asp.net 面向接口可扩展框架之使用“类型转化基础服务”测试四种Mapper(AutoMapper、EmitMapper、NLiteMapper及TinyMapper)

Asp.net 面向接口可扩展框架的“类型转化基础服务”是我认为除了“核心容器”之外最为重要的组成部分

但是前面博文一出,争议很多,为此我再写一篇类型转化基础服务和各种Mapper结合的例子,顺便对各种Mapper做个简单的优缺点对比

我对第三方组件评介有三个标准,一、可用性,二、性能,三、易用性

本例子中四种Mapper以前我都没使用过(因为以前我都用自己的Mapper),本次测试可能不准确,错误的地方请大家指正

AutoMapper使用的是4.2.1.0,需要.net4.5支持(我使用Nuget没找到到.net4.0下可用的版本)

EmitMapper使用的是1.0版本,使用.net4.0

NLite使用的是0.9.6,使用.net4.0

TinyMapper使用的是2.0.0.40,使用.net4.0

---

一、简单封装

1、各种Mappers封装项目截图

2、各种Mapper封装类

3、简单个人第一印象

3.1 AutoMapper的dll有267k,比较大,感觉功能很全面

　　支持自定义配置,支持静态方法和实例方法,提供默认实例, 支持传Type来转化,扩展性不错,功能强大

3.2 EmitMapper的dll才99k,感觉功能比较简练

　　提供默认实例,支持自定义配置

3.3 NLite的dll有646k,dll偏大,其中很多Mapper以外的功能,是个套件,如果需要其中的多项功能才比较划算(这里不展开)

3.4 TinyMapper的dll才47k,最轻量,如果功能和性能都不打折扣就完美了

只支持静态方法

二、继承类型转化科目测试

1、继承类型转化可用性测试代码

大家要看清楚,不管哪种Mapper,我都是用相同方法(GlobalServices.Instance.Convert<A, B>(a))来调用的

其一、这是为了各种Mapper测试的公平性,不要说那个多个if那个多个哈希

其二、也就是说,各种Mapper都可以使用“插件式”在本框架中运行,如果为了突然发现某种Mapper工具有“bug”,可以“秒切”为另一种Mapper,所有调用的地方几乎都不用修改

2、测试结果

没问题,以上四种Mapper轻松胜任,但是有一个细微的差别,AutoMapper是直接使用类型转化处理继承类型的转化的,对象引用都是同一个。其他mapper应该是“copy”的

3、性能测试(100万次)

A：TinyMapper最快

B：AutoMapper其次(没想明白,直接类型转化应该算“作弊”,却还没有TinyMapper快)

C：EmitMapper和NLiteMapper旗鼓相当,EmitMappe稍快

4、易用性不用说,都很简单

三、简单对象转化科目测试

1、测试代码

AutoMapper居然转化失败,实在令人失望,网上一查资料,需要扩展

2、对AutoMapper单独扩展再测

扩展后可以正常转化,而且扩展也非常简单,但是这么简单的代码为什么非要使用者写呢？我暂时还不太理解,至少易用性上是要扣分的

3、性能测试(10万次)

A：TinyMapper再拔头筹(除HandCode外),可喜可贺

B：EmitMapper其次,性能不错,Emit果然效果好

C：再次是AutoMapper,是EmitMapper的1.5倍左右,AutoMapper没有我想象的那么差

D：NLiteMapper垫底,不太明白,好像网上有说NLiteMapper也是使用Emit做的,或许我用的这个版本还不是Emit(为了尽可能的通用,我尽量使用.net4.0)

4、可用性总结,AutoMapper扣分,简单映射还是要手动注册规则

网上有人把每次使用AutoMapper时都尝试注册，虽然丑了点是个办法,不知道是否对性能有影响

四、成员名映射科目测试

1、测试代码

AutoMapper的配置规则

EmitMapper的配置规则

TinyMapper的配置规则

其实需求很简单,把A转化C,但是要把A的id属性映射到C的AId属性上,但是NLiteMapper我没找到配置方法

2、测试结果

NLiteMapper我没找到配置方法,所以AId属性没转化成功,初步判断NLiteMapper无法支持这种需求

3、性能测试(10万次)

A：TinyMapper继续头筹,而且遥遥领先

B：EmitMapper其次,比TinyMapper差太远了,对这种配置规则支持不好

C：再次是AutoMapper,比TinyMapper就差更远了,还是对这种配置规则支持不好

D：NLiteMapper性能又垫底,而且还没实现需求

4、易用性

A：TinyMapper扩展的方式最为“优美”,使用表达式增加新的映射规则,得分最高

B：AutoMapper扩展的方式其次,因为每对类型都配置是硬伤

C：EmitMapper扩展的方式有点糟糕了,就是硬编码,但是性能却比硬编码差多了,比TinyMapper都差不少(原因以后可以探讨一下)

D：NLiteMapper垫底,没实现需求

五、树状递归转化科目测试

1、测试代码

以上代码是故意把TinyMapper注释了,是为了单独测试(TinyMapper会出严重错误)

2、测试结果

2.1、单独测试TinyMapper

A：这次TinyMapper不行了,估计是我测试的例子特殊,子对象的类型是本身触发了Bug,严重的bug,不只是不能转化成功,直接死循环

注:不知道TinyMapper最新版本是否有这个问题,感兴趣的可以测试一下

B：其他三种Mapper都能胜任

3、性能测试(10万次,除TinyMapper外)

A：这次EmitMapper拔得头筹

B：AutoMapper和NLiteMapper差不多,AutoMapper稍好一点

C：TinyMapper缺席,执行会报错

4、易用性

AutoMapper硬伤,每对类型都要配置

总结一下,其一、网上有很多开源项目组件已经很强大了，如果能很好的未我所用可以大大加快项目开发的速度,甚至是项目的优化(含性能);其二、网上的项目也是人开发的,总会有这样或者那样的“问题”。我们要以一个包容的心态对待这些项目。一般来说功能全面，使用方便,bug少的性能可能不好;我们需要用其长,避其短。最好遵循“里氏代换原则”和“最少知识原则”,如果这个组件已经不适用了可以方便的替换不用满项目的修改。