使用AutoMapper实现Dto和Model的自由转换(中)【转】

转自:http://zz8ss5ww6.iteye.com/blog/1126219

注:本系列文章的代码可以在这里下载。

在上一篇文章中我们构造出了完整的应用场景,包括我们的Model、Dto以及它们之间的转换规则。下面就可以卷起袖子,开始我们的AutoMapper之旅了。 
【二】以Convention方式实现零配置的对象映射 
我们的AddressDto和Address结构完全一致,且字段名也完全相同。对于这样的类型转换,AutoMapper为我们提供了Convention,正如它的官网上所说的:

引用

AutoMapper uses a convention-based matching algorithm to match up source to destination values.

我们要做的只是将要映射的两个类型告诉AutoMapper(调用Mapper类的Static方法CreateMap并传入要映射的类型):

C#代码  

  1. Mapper.CreateMap<AddressDto, Address>();

然后就可以交给AutoMapper帮我们搞定一切了:

C#代码  

  1. AddressDto dto = new AddressDto
  2. {
  3. Country = "China",
  4. City = "Beijing",
  5. Street = "Dongzhimen Street",
  6. PostCode = "100001"
  7. };
  8. Address address = Mapper.Map<AddressDto,Address>(Dto);
  9. address.Country.ShouldEqual("China");
  10. address.City.ShouldEqual("Beijing");
  11. address.Street.ShouldEqual("Dongzhimen Street");
  12. address.PostCode.ShouldEqual("100001");

如果AddressDto中有值为空的属性,AutoMapper在映射的时候会把Address中的相应属性也置为空:

C#代码  

  1. Address address = Mapper.Map<AddressDto,Address>(new AddressDto
  2. {
  3. Country = "China"
  4. });
  5. address.City.ShouldBeNull();
  6. address.Street.ShouldBeNull();
  7. address.PostCode.ShouldBeNull();

甚至如果传入一个空的AddressDto,AutoMapper也会帮我们得到一个空的Address对象。

C#代码  

  1. Address address = Mapper.Map<AddressDto,Address>(null);
  2. address.ShouldBeNull();

千万不要把这种Convention的映射方式当成“玩具”,它在映射具有相同字段名的复杂类型的时候还是具有相当大的威力的。 
例如,考虑我们的BookStoreDto到BookStore的映射,两者的字段名称完全相同,只是字段的类型不一致。如果我们定义好了BookDto到Book的映射规则,再加上上述Convention方式的AddressDto到Address的映射,就可以用“零配置”实现BookStoreDto到BookStore的映射了:

C#代码  

  1. IMappingExpression<BookDto, Book> expression = Mapper.CreateMap<BookDto,Book>();
  2. // Define mapping rules from BookDto to Book here
  3. Mapper.CreateMap<AddressDto, Address>();
  4. Mapper.CreateMap<BookStoreDto, BookStore>();

然后我们就可以直接转换BookStoreDto了:

C#代码  

  1. BookStoreDto dto = new BookStoreDto
  2. {
  3. Name = "My Store",
  4. Address = new AddressDto
  5. {
  6. City = "Beijing"
  7. },
  8. Books = new List<BookDto>
  9. {
  10. new BookDto {Title = "RESTful Web Service"},
  11. new BookDto {Title = "Ruby for Rails"},
  12. }
  13. };
  14. BookStore bookStore = Mapper.Map<BookStoreDto,BookStore>(dto);
  15. bookStore.Name.ShouldEqual("My Store");
  16. bookStore.Address.City.ShouldEqual("Beijing");
  17. bookStore.Books.Count.ShouldEqual(2);
  18. bookStore.Books.First().Title.ShouldEqual("RESTful Web Service");
  19. bookStore.Books.Last().Title.ShouldEqual("Ruby for Rails");

【三】定义类型间的简单映射规则 
前面我们看了Convention的映射方式,客观的说还是有很多类型间的映射是无法通过简单的Convention方式来做的,这时候就需要我们使用Configuration了。好在我们的Configuration是在代码中以“强类型”的方式来写的,比写繁琐易错的xml方式是要好的多了。 
先来看看BookDto到Publisher的映射。 
回顾一下前文中定义的规则:BookDto.Publisher -> Publisher.Name。 
在AutoMapperzhong,我们可以这样映射:

C#代码  

  1. var map = Mapper.CreateMap<BookDto,Publisher>();
  2. map.ForMember(d => d.Name, opt => opt.MapFrom(s => s.Publisher));

AutoMapper使用ForMember来指定每一个字段的映射规则:

引用

The each custom member configuration uses an action delegate to configure each member.

还好有强大的lambda表达式,规则的定义简单明了。

此外,我们还可以使用ConstructUsing的方式一次直接定义好所有字段的映射规则。例如我们要定义BookDto到第一作者(Author)的ContactInfo的映射,使用ConstructUsing方式,我们可以:

C#代码  

  1. var map = Mapper.CreateMap<BookDto,ContactInfo>();
  2. map.ConstructUsing(s => new ContactInfo
  3. {
  4. Blog = s.FirstAuthorBlog,
  5. Email = s.FirstAuthorEmail,
  6. Twitter = s.FirstAuthorTwitter
  7. });

然后,就可以按照我们熟悉的方式来使用了:

C#代码  

  1. BookDto dto = new BookDto
  2. {
  3. FirstAuthorEmail = "[email protected]",
  4. FirstAuthorBlog = "matt.amazon.com",
  5. };
  6. ContactInfo contactInfo = Mapper.Map<BookDto, ContactInfo>(dto);

如果需要映射的2个类型有部分字段名称相同,又有部分字段名称不同呢?还好AutoMapper给我们提供的Convention或Configuration方式并不是“异或的”,我们可以结合使用两种方式,为名称不同的字段配置映射规则,而对于名称相同的字段则忽略配置。 
例如对于前面提到的AddressDto到Address的映射,假如AddressDto的字段Country不叫Country叫CountryName,那么在写AddressDto到Address的映射规则时,只需要:

C#代码  

  1. var map = Mapper.CreateMap<AddressDto, Address>();
  2. map.ForMember(d => d.Country, opt => opt.MapFrom(s => s.CountryName));

对于City、Street和PostCode无需定义任何规则,AutoMapper仍然可以帮我们进行正确的映射。

时间: 2024-10-10 10:23:12

使用AutoMapper实现Dto和Model的自由转换(中)【转】的相关文章

使用AutoMapper实现Dto和Model的自由转换(上)【转】

转自:http://zz8ss5ww6.iteye.com/blog/1126205 注:本系列文章的代码可以在这里下载. 在实际的软件开发项目中,我们的“业务逻辑”常常需要我们对同样的数据进行各种变换.例如,一个Web应用通过前端收集用户的输入成为Dto,然后将Dto转换成领域模型并持久化到数据库中.另一方面,当用户请求数据时,我们又需要做相反的工作:将从数据库中查询出来的领域模型以相反的方式转换成Dto再呈现给用户.有时候我们还会面临更多的数据使用需求,例如有多个数据使用的客户端,每个客户端

使用AutoMapper实现Dto和Model的自由转换(上)

在实际的软件开发项目中,我们的"业务逻辑"常常需要我们对同样的数据进行各种变换.例如,一个Web应用通过前端收集用户的输入成为Dto,然后将Dto转换成领域模型并持久化到数据库中.另一方面,当用户请求数据时,我们又需要做相反的工作:将从数据库中查询出来的领域模型以相反的方式转换成Dto再呈现给用户.有时候我们还会面临更多的数据使用需求,例如有多个数据使用的客户端,每个客户端都有自己对数据结构的不同需求,而这也需要我们进行更多的数据转换. 频繁的数据转换琐碎而又凌乱,很多时候我们不得不:

使用AutoMapper实现Dto和Model的自由转换(中)

在上一篇文章中我们构造出了完整的应用场景,包括我们的Model.Dto以及它们之间的转换规则.下面就可以卷起袖子,开始我们的AutoMapper之旅了. [二]以Convention方式实现零配置的对象映射 我们的AddressDto和Address结构完全一致,且字段名也完全相同.对于这样的类型转换,AutoMapper为我们提供了Convention,正如它的官网上所说的: 引用 AutoMapper uses a convention-based matching algorithm to

使用AutoMapper实现Dto和Model的自由转换(下)

书接上文.在上一篇文章中我们讨论了使用AutoMapper实现类型间1-1映射的两种方式--Convention和Configuration,知道了如何进行简单的OO Mapping.在这个系列的最后一篇文章我想基于我们的需求讨论一些中级别的话题,包括:如何实现类型体型之间的映射,以及如何为两个类型实现多个映射规则. [四]将一个类型映射为类型体系 先回顾一下我们的Dto和Model.我们有BookDto,我们有Author,每个Author有自己的ContactInfo.现在提一个问题:如何从

使用AutoMapper实现Dto和Model的自由转换(下)【转】

转自:http://zz8ss5ww6.iteye.com/blog/1126330 书接上文.在上一篇文章中我们讨论了使用AutoMapper实现类型间1-1映射的两种方式——Convention和Configuration,知道了如何进行简单的OO Mapping.在这个系列的最后一篇文章我想基于我们的需求讨论一些中级别的话题,包括:如何实现类型体型之间的映射,以及如何为两个类型实现多个映射规则. [四]将一个类型映射为类型体系 先回顾一下我们的Dto和Model.我们有BookDto,我们

AutoMapper完成Dto与Model的转换

在实际的软件开发项目中,我们的"业务逻辑"常常需要我们对同样的数据进行各种变换. 例如,一个Web应用通过前端收集用户的输入成为Dto,然后将Dto转换成领域模型并持久化到数据库中.相反,当用户请求数据时,我们又需要做相反的工作:将从数据库中查询出来的领域模型以相反的方式转换成Dto再呈现给用户. 有时候我们还会面临更多的数据使用需求,例如有多个数据使用的客户端,每个客户端都有自己对数据结构的不同需求,而这也需要我们进行更多的数据转换. 频繁的数据转换琐碎而又凌乱,很多时候我们不得不做

简单使用AutoMapper实现DTO转换

DTO(Data Transfer Object)数据传输对象,只是传输数据,完成与领域对象之间的转换,并不包含领域业务处理. 当领域模型设计人员只关注核心业务,满足于领域模型的精巧,而不关心具体实现的时候,DTO就会大量出现. 系统复杂化后,DTO可能是多个Domain Model组合实现. 为什么要使用DTO? 1.隔离Domain Model,使改动领域模型而不影响UI,保持领域模型的安全,不暴露业务逻辑. 2.在分布式模式下,不同的场景使用相同的数据结构有不同的需求. 简单示例: Ord

JSP隐含变量和Spring中Model在EL表达式中的读取顺序

偶然中存在着必然,必然中存在着偶然 偶然出现的bug,必然存是由代码的不合理甚至错误的 代码逻辑越长,越复杂,就越容易出现bug 之前项目里几次偶然出现了一个bug,简单的描述就是第一次新增了之后进行一个B操作,之后在新增一次,页面中的一个隐含变量会"记住"这个新增之后的id,因为这个需要连续两次新增且在第一次新增之后进行B操作之后才会出现,所以很长时间里面都是偶然出现. 定位问题的过程就是进行很多次的操作,然后逐个排除.尝试自己的猜测,再次进行代码级的排除.定位这种问题一定要有一定的

spring mvc将model存入到session中去

今天需要针对预览功能将参数通过window.open(url+参数)的方式请求后台方法,进行页面跳转,然而当参数太大时,通过url的方式会导致请求参数过长而失败.所以只能改用post方式,将参数以bean或者requestbosy的方式传递给controller,但是这种方会使原来能自动跳转的url不跳转,目前还没找到原因.通过redirect的方式会导致塞到model的参数无法获取,因此需要将model参数存入到session中去.参考了以下两篇原文,供大家参考. 原文参考:http://bl