AutoMapper(上)

映射前后操作

偶尔有时候，在映射发生之前或之后，你可能需要执行一些自定义的逻辑。这可能是很少见的事情，因为在AutoMapper之外处理这些事情是更明显的。你可以创建一个映射前后的全局操作：

Mapper.CreateMap<Source, Dest>()
    .BeforeMap((src, dest) => src.Value = src.Value + 10)
    .AfterMap((src, dest) => dest.Name = "John");

或者在映射期间，创建映射前后的回调函数：

int i = 10;
Mapper.Map<Source, Dest>(src, opt => {
    opt.BeforeMap((src, dest) => src.Value = src.Value + i);
    opt.AfterMap((src, dest) => dest.Name = HttpContext.Current.Identity.Name);
});

当你需要将上下文信息注入映射前后的行为中时，后者的配置很有用。

条件映射

在属性映射之前，AutoMapper允许将必须满足的条件添加到属性上。

这个用在下面这种情况，比如有两个类，分别是Aliens（外星人）和Person（人）类，都有一个Age属性，我们都知道我们人类的年龄都是非负数，所以我们这里用unsigned int(无符号整数)类型。但是，目前人类科技水平有限，还没有研究出是否有外星人存在，就更无法确定其年龄属性了，所以我们这里假设外星人的年龄可以为负数（如果你反驳我你也没依据啊，暂且就这样吧），那么就定义其为int类型，如果我们要将外星人映射到人类上，其实就是uint到int之间的映射：

namespace FrontAutoMapper
{
    class Program
    {
        static void Main(string[] args)
        {
//创建映射，映射条件是源类型的Age属性在区间(0,149)范围内
            Mapper.CreateMap<Aliens, Person>().ForMember(dest => dest.Age, opt => opt.Condition(src => src.Age > 0 && src.Age < 149));

            var p1 = Mapper.Map<Person>(new Aliens() { Age = -1 });//不符合映射条件
              var p2 = Mapper.Map<Person>(new Aliens() { Age = 0 });//不符合映射条件
              var p3 = Mapper.Map<Person>(new Aliens() { Age = 1 });//符合映射条件
              var p4 = Mapper.Map<Person>(new Aliens() { Age = 148 });//符合映射条件
              var p5 = Mapper.Map<Person>(new Aliens() { Age = 149 });//不符合映射条件
              Console.WriteLine(p1.Age);//映射不成功，返回Person.Age默认值22
            Console.WriteLine(p2.Age);//映射不成功，返回Person.Age默认值22
            Console.WriteLine(p3.Age);//映射成功，返回新值1
            Console.WriteLine(p4.Age);//映射成功，返回新值148
            Console.WriteLine(p5.Age);//映射不成功，返回新值22
            Console.Read();
        }
    }
    public class Person
    {
        public Person()
        {
            Age = 22;
        }
        public uint Age { set; get; }//Person的Age属性默认值是22
    }

    public class Aliens
    {
        public Aliens()
        {
            Age = -23;
        }
        public int Age { get; set; }//Aliens的Age属性默认值是-23
    }
}

这个例子是将年龄Age在区间(0,149)范围内的外星人映射成人，执行结果如下，和预测结果一致。

配置

初始化

初始化是配置AutoMapper受人欢迎的模式，每个应用域应该配置一次：

//初始化配置文件
Mapper.Initialize(cfg =>
{
    cfg.CreateMap<Aliens, Person>();
    cfg.AddProfile<AliensPersonProfile>();//添加一个配置文件
});

映射配置是静态的，此后不应该改变了。

Profile实例

可用来组织AutoMapper配置

namespace ConditionalMapping
{
    public class AliensPersonProfile : Profile
    {
        protected override void Configure()
        {
            //放一些CreateMap(...)等映射配置操作

        }
    }
}

自定义一个继承了Profile类的类，然后重写Configure方法，在该方法中放一些映射的配置。

像下面这样初始化自定义的配置文件：

//初始化配置文件
Mapper.Initialize(cfg =>
{
    cfg.AddProfile<AliensPersonProfile>();//添加一个配置文件
});

命名惯例

可以设置源和目标的命名惯例。

//初始化配置文件
Mapper.Initialize(cfg =>
{
    cfg.SourceMemberNamingConvention=new LowerUnderscoreNamingConvention();
    cfg.DestinationMemberNamingConvention=new PascalCaseNamingConvention();
});

也可以在配置文件中的Configure方法中设置：

protected override void Configure()
{
    SourceMemberNamingConvention = new LowerUnderscoreNamingConvention();
    DestinationMemberNamingConvention = new PascalCaseNamingConvention();
}

小试牛刀：

在Aliens类中添加如下代码：

public string MyName { set; get; }

在Person类中添加如下代码：

public string my_name { get; set; }

结果如下，和预测结果一致：

可见，这种映射配置就是告诉AutoMapper这两种命名惯例可以相互映射。而且需要注意的是，这两句代码可放在CreateMap()方法之后。

替换字符

在成员名字映射期间，也可以替换个别的字符或者整个单词。

配置Mapper(可在Initialize方法或配置文件中均可，后面不再提示)，注意一定要在CreateMap方法之前，配置替换字符，否则没有效果。这也符合逻辑，只有先添加替换条件，才能按条件映射嘛。

cfg.ReplaceMemberName("Ä", "A");
cfg.ReplaceMemberName("í", "i");
cfg.ReplaceMemberName("Tool", "Car");
cfg.AddProfile<AliensPersonProfile>();

小试牛刀：

在Aliens类中添加如下代码：

public int Ävíator { get; set; }
public string ToolName { get; set; }

在Person类中添加如下代码：

public int Aviator { get; set; }
public string CarName { get; set; }

结果如下，和预测结果一致：

识别前缀/后缀

有时候你的源类型和目标类型的属性有公共的前缀/后缀，由于这些命名不匹配的缘故，使你不得不处理这些自定义的成员映射。为了实现这个，可以识别前后缀：

小试牛刀：

在Aliens类中添加如下代码：

public string PGender { get; set; }

在Person类中添加如下代码：

public string Gender { get; set; }

可见，源类型中有一个前缀为“P”的字段PGender，要想成功映射为Person，就必须识别出前缀“P”，所以在Mapper的配置中添加代码（注意，添加到CreateMap方法之前，否则无效）：

cfg.RecognizePrefixes("P");

结果如下，和预测结果一致：

默认情况下，AutoMapper识别前缀“Get”,如果你需要清除前缀：

cfg.ClearPrefixes();

全局属性/字段过滤

默认情况下，AutoMapper映射每一个公共的属性/字段。你可以使用属性/字段过滤器过滤出不需要映射的属性/字段：

//不映射任何字段
cfg.ShouldMapField = fi => false;
//只映射getter是private的属性
cfg.ShouldMapProperty = pi => pi.GetMethod != null && pi.GetMethod.IsPrivate;
cfg.AddProfile<AliensPersonProfile>();

小试牛刀：

分别给Aliens和Person类添加下面这段代码：

private string code;
public string Code
{
    private get { return code; }
    set { code = value; }
}

Main方法中添加代码：

var p10 = Mapper.Map<Person>(new Aliens() { Age = 44,Code = "111"});
Console.WriteLine(string.Format("Person.Age={0},Person.code={1}",p10.Age,p10.code));//22,111

结果和预测一样：

解释一下：

我们在配置中添加了过滤器，只允许getter是private的属性映射，而Person的Age属性getter默认是public的，所以没有将我们给的值44映射到，因而返回默认的22，而Person的Code属性的getter是私有的，所以映射到了，但是要想取到映射后的值，我们只能通过公有的字段来获得。

配置可见性

默认情况下，AutoMapper只识别公有成员。虽然可以映射到私有的setter，但是如果整个属性是private/internal的，那么就会跳过internal/private的方法和属性。为了命令AutoMapper识别具有其他可见性的成员，重写默认的过滤器ShouldMapField或ShouldMapProperty:

Mapper.Initialize(cfg =>
{
    // 映射具有public或internal的getter的属性
    cfg.ShouldMapProperty = p => p.GetMethod.IsPublic || p.GetMethod.IsAssembly;
    cfg.CreateMap<Source, Destination>();
});
时间： 2024-10-13 19:53:10

AutoMapper(上)的相关文章

使用AutoMapper实现Dto和Model的自由转换（上）

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

【AutoMapper官方文档】DTO与Domin Model相互转换（上）

前言 Flattening-复杂到简单 Projection-简单到复杂 Configuration Validation-配置验证 Lists and Array-集合和数组 Nested mappings-嵌套映射 后记 上一篇<[道德经]漫谈实体.对象.DTO及AutoMapper的使用 >,因为内容写的有点跑偏,关于AutoMapper的使用最后只是简单写了下,很明显这种简单的使用方式不能满足项目中复杂的需要,网上找了下AutoMapper相关文档,但差不多都是像我一样简单的概述下,看

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

转自:http://zz8ss5ww6.iteye.com/blog/1126205 注:本系列文章的代码可以在这里下载. 在实际的软件开发项目中,我们的“业务逻辑”常常需要我们对同样的数据进行各种变换.例如,一个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后遇到的“Missing map”与“Missing type map configuration or unsupported mapping”问题

前几天发现 AutoMapper 3.3 的一个性能问题(详见:遭遇AutoMapper性能问题:映射200条数据比100条慢了近千倍),于是将 AutoMapper 升级至最新的 5.1.1 看是否也存在这个性能问题. 升级中想当然地将之前的map配置代码: Mapper.CreateMap<AEntity, ADto>(); Mapper.CreateMap<BEntity, BDto>(); 改为: Mapper.Initialize(cfg => cfg.Create

【G】开源的分布式部署解决方案（二） - 好项目是从烂项目基础上重构出来的

G.系列导航 [G]开源的分布式部署解决方案 - 预告篇 [G]开源的分布式部署解决方案(一) - 开篇 [G]开源的分布式部署解决方案(二) - 好项目是从烂项目基础上重构出来的 分析目前项目结构 眼前出现这么一坨坨的文件夹,相信很多人已经看不下去了.是的,首先就是要把它给做掉. 按照这个项目文件夹的命名意图,大概可以划分如下: 1.Business:业务代码 2.Data:数据访问 3.Helpers:辅助类(通用类库之类的) 4.Models:各种模型(包括视图模型) 5.theme:皮肤

当EntityFramework爱上AutoMapper

有时候相识即是一种缘分,相爱也不需要太多的理由,一个眼神足矣,当EntityFramework遇上AutoMapper,就是如此,恋爱虽易,相处不易. 在DDD(领域驱动设计)中,使用AutoMapper一般场景是(Domain Layer)领域层与Presentation Layer(表现层)之间数据对象的转换,也就是DTO与Domin Model之间的相互转换,但是如果对AutoMapper有深入了解之后,就会发现她所涉及的领域不仅仅局限如此,应该包含所有对象之间的转换.另一边,当Entit

AutoMapper

AutoMapper 使用实践 一.   使用意图 常常在开发过程中,碰到一个实体上的属性值,要赋值给另外一个相类似实体属性时,且属性有很多的情况.一般不利用工具的话,就要实例化被赋值实体B,然后再将实体A的字段一个个赋值给B的属性,单单写这些没有技术含量的赋值语句,就要用很大的代码篇幅.假如做得好一点的话,一般就是利用反射的方式,将A属性赋值给B,当然用反射的话,要顺利将A的属性,赋值B的属性,这样确实能够减少代码篇幅,那就要有一些约束或者限制,例如属性名称要相同,属性的数据类型要相同,这样反