IT教程 ·

【5min+】 工具映射只有AutoMapper?试试Mapster

go微服务框架kratos学习笔记八 (kratos的依赖注入)

系列引见

【五分钟的dotnet】是一个应用您的碎片化时刻来进修和雄厚.net学问的博文系列。它所包含了.net系统中大概会涉及到的各个方面,比方C#的小细节,AspnetCore,微效劳中的.net学问等等。
5min+不是凌驾5分钟的意义,"+"是学问的增添。so,它是让您消费5分钟以下的时刻来提拔您的学问储备量。

正文

一谈到如安在.Net中举行对象映照,大概大部分同砚都邑脱口而出:“运用AutoMapper!”。 是的,AutoMapper 是一个非常成熟的对象映照器。停止到写这篇文章,您能在Nuget高低载到的AutoMapper包的版本为:v9.0.0,而对应的 Github 的 star 已高达7K。

对了,谈到AutoMapper就不得不谈起它的作者(之一):“JIMMY BOGARD”。或许您没有听过这个名字,然则您肯定听过他的另一个作品:MediatR(在微软的官方示例EShop中也运用了MediatR)。同时,“JIMMY BOGARD” 也是提出“将范畴事宜附加在聚合根”上的人,为范畴驱动设想(DDD)做出了很大的孝敬。在微软官方文档中,您能够看到该处说起到了“JIMMY BOGARD”:

【5min+】 工具映射只有AutoMapper?试试Mapster IT教程 第1张

好吧,优异的人老是优异。照样回到本日的正文,对象映照东西。固然,关于AutoMapper人人大概再熟习不过了,而且它的知名度和热度也居高不下,看一看百度搜刮效果就知道了:

【5min+】 工具映射只有AutoMapper?试试Mapster IT教程 第2张

然后再来看一看,我们本日要引见的主角:Mapster。 不知道有若干同砚听过它?应当很少吧,这一点从百度搜刮也能够看出来:

【5min+】 工具映射只有AutoMapper?试试Mapster IT教程 第3张

额………………彷佛差别有点大哈。而且在这些搜刮效果中,有效的信息只要那末几条,个中能看的文章就只要一条,而且照样出自于博客园。 来自 “dudu” 大佬客岁的一篇文章: 。 再来看一看Github的状况,间隔我写这一篇稿子的时刻,Star数只要 518 个。

【5min+】 工具映射只有AutoMapper?试试Mapster IT教程 第4张

一个契机

我们先来回忆一下AutoMapper是怎样运用的:

如今有两个类,一个叫做MyEntity ,一个叫做 MyDto。 在我们誊写应用层代码的时刻,将数据转换为Dto是很罕见的一种操纵,所以这也是我们须要对象映照器的缘由。 假定,这两个类的构造是酱紫的:

public class MyEntity
{
    public string Name { get; set; }

    public int No { get; set; }
}

public class MyDto
{
    public string Name { get; set; }

    public int No { get; set; }
}

很广泛,也是很罕见的范例。那末假如我们要用AutoMapper来完成两者之间的转换呢?

var configuration = new MapperConfiguration(cfg =>
{
    cfg.CreateMap<MyEntity, MyDto>();
});

var mapper = configuration.CreateMapper();

var r = mapper.Map<MyDto>(new MyEntity() { Name = "xxx", No = 111 });

这是9.0的版本,假如您用过之前的版本大概会有点差别,比方老版本会运用Initialize要领来设置。然则思绪都是一样的,也就是说,我们须要先设置对象与对象之间的相互关联,然后建立一个Mapper,在.NET core中我们平常会在Configura设置好今后,将mapper注册为一个单例,今后运用的话经由过程依靠注入就能够运用了。

是的,这类写法逻辑清楚没有一点问题。那末是什么契机让我挑选摒弃AutoMapper呢? 大概您会认为是机能问题,毕竟在上面 dudu 的那篇文章的标题真的很有吸引力。 但这只是很小的一部分缘由。

当我在写一些库的时刻,我须要用到对象转换的功用,假如本身造轮子写一个的话也不现实(能够看看AutoMapper的源码,内里有若干的表达式树写法),所以我尝试引入第三方的映照东西,和人人一样我第一回响反映就是AutoMapper。然则在评价的时刻,我发明:平常来说,mapper对象全局只须要一个,那末这个mapper对象是在我写的库中运用,照样交由用户来建立呢? 假如在库中建立,那末用户必需在运用库的时刻举行设置,比方库公然一个托付来设置:

service.AddMyLibary(config=>
{
    //config wrap automapper
})

就好比上面的写法。大概您如今正在运用的框架中就是运用了这类体式格局。 固然也不是说如许不好,然则我个人感觉很新鲜。

另有一点就是,AutoMapper必需要在举行了设置今后才完成映照,假如我不供应设置的话,就是抛出一个非常。

所以,基于这两点,我就想有无 1:简朴的映照不须要设置 2:能够在任何地方举行设置 的对象映照东西。

是的,厥后我采用了Mapster,很早之前就已听闻该东西,然则一向没有对比着运用过它。

假如将上面AutoMapper举行映照的代码修正一下,转换为Mapster的版本,是如许的:

var entity = new MyEntity() { Name = "xxx", No = 111 };
var r = entity.Adapt<MyDto>();

是的,没有看错,只要一句代码。(虽然我写了两句)。 当我们安装了Mapster今后,object对象就会具有一个 Adapt() 的扩大要领。只须要挪用该要领就能够直接完成转换。关于简朴的关联,我们基本都不须要举行设置。

那末关于庞杂的映照呢? Mapster 供应了一个 TypeAdapterConfig<T,T> 的静态泛型范例来举行设置,所以我们能够在任何地方誊写设置:

TypeAdapterConfig<MyEntity, MyDto>
    .NewConfig()
    .Map(s => s.Name, d => d.Name + "_Mapster");

就像如许,我们就完成了这组对象的庞杂映照关联。(Name内里加上"_Mapster"后缀)。

小试牛刀

固然,上面的例子只是一个很基本的范例,然则我们经常会碰到范例内里具有别的的范例,这类嵌套关联能行吗? 所以我们把上面的实体举行变动:

public class MyDto
{
    public string Name { get; set; }

    public int No { get; set; }

    public string UoyoName { get; set; }
}

public class MyEntity
{
    public string Name { get; set; }

    public int No { get; set; }

    public ChildEntity UoyoCSharp { get; set; }
}

public class ChildEntity
{
    public string Name { get; set; }
}

在MyEntity内里具有一个ChildEntity的范例。 “什么?您问我为何不好好定名,比方ChildEntity就定名为Child呀,为何要定名成读不懂的东西。” 因为……您定名范例了,基本都不必写设置,Mapster会自动完成映照。 所以基于这个不规则的定名,我们只须要举行下面的设置就好了:

TypeAdapterConfig<MyEntity, MyDto>
           .NewConfig()
           .Map(s => s.UoyoName, d => d.UoyoCSharp.Name);

就是这么简朴。那末别的的高等映照呢??? 请自行跳转自查询。 因为本文不是教程篇所以就偷懒了哈。固然官方的文档也很少,只须要半个小时,大概您就学完了。

末了,再来说一说人人很体贴的一个问题吧:它和AutoMapper比较,机能有什么差别呢? 因为选型评价的时刻我也并没有太斟酌机能这个要素,所以就没有举行测试,然则在Github的申明页,官方给了一个测试比较:

【5min+】 工具映射只有AutoMapper?试试Mapster IT教程 第5张

好吧,差别相对来说照样挺大的。然则毕竟我没有举行确实的考证,也不会对它举行无脑吹。详细状况还请列位大佬自行测试。

 

 

Nginx总结(七)Nginx服务器的日志管理及配置

参与评论