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少的性能可能不好;我们需要用其长,避其短。最好遵循“里氏代换原则”和“最少知识原则”,如果这个组件已经不适用了可以方便的替换不用满项目的修改。
