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、性能测试(10万次)

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硬伤,每对类型都要配置

时间: 2024-10-09 22:08:59

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

Asp.net 面向接口可扩展框架之消息队列组件

消息队列对大多数人应该比较陌生.但是要提到MQ听说过的人会多很多.MQ就是英文单词"Message queue"的缩写,翻译成中文就是消息队列(我英语差,翻译错了请告知). PS:话说国人熟悉MQ比消息队列多,是不是因为国人的外语水平高于国语水平好几个数量级 1.看一下度娘怎么解释消息队列 参考链接:消息队列_百度百科 度娘解释消息队列是在两台计算机间传输的,套句很时髦的说法就是用来做分布式传输的,是个很高大上的东西 2.我的看法稍有不同 我更追溯到“消息队列”的字面“本源”的意思.我

Asp.net 面向接口可扩展框架之业务规则引擎扩展模块

随着面向接口可扩展框架的继续开发,有些功能开发出现了"瓶颈",有太多的东西要写死才好做.但写死的代码扩展性是非常的不好,迷茫中寻找出入... 进而想到我以前开发的好几个项目,都已有一定的可配置能力,想想怎么把这些地方的代码抽象提取出来.进而想到"业务规则引擎",网上找了几个都不太入"眼",就抽时间再造个"轮子" 业务规则引擎在很多成熟的工作流引擎中都有相应的模块,是工作流的核心之一.但是除了工作流很多业务都需要业务规则引擎,所

Asp.net 面向接口可扩展框架之类型转化基础服务

新框架正在逐步完善,可喜可贺的是基础服务部分初具备模样了,给大家分享一下 由于基础服务涉及太广,也没开发完,这篇只介绍其中的类型转化部分,命名为类型转化基础服务,其实就是基础服务模块的类型转化子模块 说到类型转化必须要清楚.net的类型,类型都不清楚何来类型转化 1.Primitive类型 1.1 这个概念估计很多人都没听说过,Primitive不是一个新类型,而是.net类型中最基本的一种分类,是基元类型的意思       MS将类型分为三类:Primitive(基元类型).Complex(复

Asp.net 面向接口可扩展框架之数据处理模块及EntityFramework扩展和Dapper扩展(含干货)

面向接口数据处理模块是什么意思呢?实际上很简单,就是使用面向接口的思想和方式来做数据处理. 还提到EntityFramework和Dapper,EntityFramework和Dapper是.net环境下推崇最高的两种ORM工具. 1.EntityFramework是微软出的根正苗红的.netd的ORM工具,直接在Vs工具和Mvc框架中集成了,默认生成的项目就是使用EntityFramework的;微软也一直都在维护更新升级,最新版本最新版本都在EF7了.也迁移到了最新的.net Core平台了

Asp.net 面向接口可扩展框架之“Mvc扩展框架及DI”

标题“Mvc扩展框架及DI”有点绕口,我也想不出好的命名,因为这个内容很杂,涉及多个模块,但在日常开发又密不可分 首先说Mvc扩展框架,该Mvc扩展就是把以前的那个Mvc分区扩展框架迁移过来,并优化整合了一下 一.Mvc扩展框架主要功能: 1.Mvc的依赖注入(DI)功能(类MvcDependency) 依赖IContainerFactory接口,不再依赖具体容器 2.Mvc全局过滤器(GlobalFilterProvider) 配置在Mvc的依赖注入容器中就能自动易用上,其实逻辑很简单,就是继

面向接口可扩展框架

Asp.net 面向接口可扩展框架之核心容器(含测试代码下载) 新框架的容器部分终于调通了!容器实在太重要了,所以有用了一个名词叫“核心容器”. 容器为什么那么重要呢?这个有必要好好说道说道. 1.首先我们从框架名称面向接口编程说起,什么是面向接口编程?(这个度娘回答一下) 解读一下:类是个体的定义(建模), 个体的每一方面都可以是一个接口 说白点,其一接口可以代表对象(类)一个方面,再说透点对象可能是多面手(继承多个接口),能在不同场景(作为不同接口的实例)下正常工作 其二每个接口可以有不同实

面向接口可扩展框架之“Mvc扩展框架及DI”

面向接口可扩展框架之“Mvc扩展框架及DI” 标题“Mvc扩展框架及DI”有点绕口,我也想不出好的命名,因为这个内容很杂,涉及多个模块,但在日常开发又密不可分 首先说Mvc扩展框架,该Mvc扩展就是把以前的那个Mvc分区扩展框架迁移过来,并优化整合了一下 一.Mvc扩展框架主要功能: 1.Mvc的依赖注入(DI)功能(类MvcDependency) 依赖IContainerFactory接口,不再依赖具体容器 2.Mvc全局过滤器(GlobalFilterProvider) 配置在Mvc的依赖注

Asp.net 面向接口框架之应用程序上下文作用域组件

在团队中推广面向接口开发两年左右,成果总体来说我还是挺满意的,使用面向接口开发的模块使用Unity容器配置的功能非常稳定也很好扩展. 但是由于当时开发的匆忙(边开发边应用),留下一些比较致命的问题: 1.很多接口定义的不合理,通用性和扩展性不好 2.固定死了使用Unity容器,如果更大面积推广有问题,有些人已经很熟悉其他容器了,再来重新学Unity没有必要 3.配置比较麻烦,需要简化 所以我觉得有必要重新开发一个框架,对原框架取其精华去其糟粕,再吸收开源项目(含微软开放源代码的部分),争取做出一

Asp.net 面向接口框架之核心容器

新框架的容器部分终于调通了!容器实在太重要了,所有用了一个名词叫“核心容器”. 容器为什么那么重要呢?这个有必要好好说道说道. 1.首先我们说从框架名称面向接口编程说起,什么是面向接口编程?(这个度娘回答一下) 解读一下:类是个体的定义(建模), 个体的每一方面都可以是一个接口 说白点,其一接口可以代表对象(类)一个方面,再说透点对象可能是多面手(继承接口),能在不同场景(作为不同接口的实例)工作 其二每个接口可以不同实现,只要实现了这个接口,基本上就可以替换这个位置来正常工作 2.我觉得面向接