autoMapper-- 无缘也成有缘(一)

与autoMapper是在做高效平台项目一开始的时候某某同学极力推荐我看的,看了以后感觉这个东西可真的很好使,下面就分享给大家!

先介绍一下它的产生背景,结合我现在在做的项目来说,这个项目的前台用的是MVC,后台用的是WCF+三层+工厂+反射,看上去很高大上的样纸 ~~,于是开始了冲动的代码之旅,可是在写数据契约的时候发现了EF中生成的实体我用到了可能很多,于是写啊~复制啊~粘贴啊~原以为很霜,全部纯手工打造,可是遇到了AutoMapper,我后悔~莫及~~

在看大神们博客的过程中,发现了一种叫做贫血模型的,其实也就是我们的数据表映射处理出来的实体模型,这种模型只有固定数量的属性,如果你想用多个模型中的属性时,就会山路十八弯了,举个例子

如果把Entity Framework比作机关枪,那实体类的属性就是子弹,每颗子弹只能攻击唯一对应的目标,在射击过程中,只要有一颗子弹攻击的目标不存在,机枪就会卡壳(子弹决定目标?)。这时,Entity Framework成为了一堆废铁。

为什么不由目标决定子弹?出现什么目标,用什么子弹,既节省子弹,又不会卡壳。也就是根据查询结果给对应的实体类属性赋值。难道这个新式武器也有设计缺陷,没有考虑到这样的应用场景?还是我们不会使用?

首先,下载

2、下面是我做的一个小例子:要记得添加引用哦!

<span style="font-size:14px;"><strong><span style="color:#ff0000;">using AutoMapper;
</span></strong>
namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            //创建实体映射规则,onclass为源数据契约、TimeTable为目标数据契约
            Mapper.CreateMap<OnClass, TimeTable>();
            //为源数据赋值
            OnClass onclass = new OnClass
            {
                OnClassID = "001",
                OnClassNo = "002",
                OnClassName = "dandan"
            };
            //将源数据的值映射给目标数据
            TimeTable timetable = Mapper.Map<TimeTable>(onclass);
            //显示
           Console.WriteLine(timetable.OnClassID+timetable.OnClassNo+timetable.OnClassName);
        }
    }
}
</span>

看一下效果:

简单的AutoMapper介绍完了,有没有感觉到它的巨大作用呢?如果你的EF不能满足你的程序实现,需要调用其他模型时,请考虑它把~

时间: 2024-10-25 03:10:31

autoMapper-- 无缘也成有缘(一)的相关文章

转转的接口json

{ "respCode": "0", "respData": [ { "uid": "48470233694990", "updateTime": "2天前", "discountTip": "", "status": "8", "labels": { "us

MVC+UnitOfWork+Repository+DomainObject+EF 之我见

UnitOfWork+Repository模式简介: 每次提交数据库都会打开一个连接,造成结果是:多个连接无法共用一个数据库级别的事务,也就无法保证数据的原子性.一致性.解决办法是:在Repository的CRUD操作基础上再包装一层,提供统一的入口,让服务层调用.同一个UnitOfWork实例对象下所有的Repository都共同一个数据库上下文对象(ps:EF用的是DbContext),也就是共用一个事物.提交数据库时,只要有一个操作失败,那么所有的操作都被视为失败. 项目结构: 关键代码:

领域Model?

前言 领域驱动设计里有很多东西,我们可以应用在各种各样的开发模式里,所以接下来说的一些东西,我们可以部分使用. 说道领域驱动的领域,大家肯定就要开始说Bounded Context,聚合,聚合根,容易让大家搞糊涂. 我觉得先抛开这些概念,后面再来说如何设计聚合,先简单来说. 模型 过去,我们在多层设计里定义了很多Model, 数据库的Model(DB Entity), 然后为了不依赖数据库,我们有设计了业务的Domain Model, 同时我们又设计了ViewModel, 这样一般也没什么问题,

MVC+UnitOfWork+Repository+EF 之我见

UnitOfWork+Repository模式简介: 每次提交数据库都会打开一个连接,造成结果是:多个连接无法共用一个数据库级别的事务,也就无法保证数据的原子性.一致性.解决办法是:在Repository的CRUD操作基础上再包装一层,提供统一的入口,让服务层调用.同一个UnitOfWork实例对象下所有的Repository都共同一个数据库上下文对象(ps:EF用的是DbContext),也就是共用一个事物.提交数据库时,只要有一个操作失败,那么所有的操作都被视为失败. 项目结构: 关键代码:

有缘就珍惜,无缘就放弃,别累着自己

其实,谁喜欢你,你能感觉得到.你喜欢谁,他对你爱不爱,在不在意,你也能感觉到.有时候,聪明如你,傻就傻在习惯欺骗自己. 承诺了不该给的承诺,坚持了没必要的坚持.爱情这件事,勉强不了,住不进你心里的人就放他走,你走不进的世界提前先掉头. 茶凉了,就别再续了,再续也不是原来的味道了.人走了,就别再留了,再留下也不是原来的感觉了. 情没了,就别回味了,再回味也不是原来的心情了.慢慢的都会远,渐渐的都会淡.拥有时好好珍惜,离开了默默祝福.人生的旅途,没有人是应该要陪你走到最后的. 不适合的鞋子,就不要硬

第四十二回 巧相遇衷言托心事 怕麻烦快意成婚姻

文鑫载美丽到她姐姐的住家的楼下,美丽说:"今这么晚了,明日再上去.明日上午您到此处来,我带您买点东西,在我姐家吃饭.我妈刚好从家乡来了.这样我姐姐.姐夫.母亲同意,就可结婚.如果她们同意,明晚叫我姐.姐夫.母亲到您处吃饭,就算定婚,晚上我就可留在您处了." 文鑫想不到,踏破铁鞋无处寻,得来全不费工夫.以前选择那么多,也不顺眼,今美丽皮肤雪白,不高不矮,不肥不瘦,脸上浮现桃红,且有酒窝,煞是好看.特别是她那灿烂的一笑,夺人魂魄,有着性魅力.与种菜的碧如比起来,胜出多了.碧如初中未毕业,美

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

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

对象映射工具AutoMapper介绍

AutoMapper是用来解决对象之间映射转换的类库.对于我们开发人员来说,写对象之间互相转换的代码是一件极其浪费生命的事情,AutoMapper能够帮助我们节省不少时间. 一. AutoMapper解决了什么问题? 要问AutoMapper解决了什么问题? 难道不是对象映射转换的问题吗? 当然是,不过我们可以问深入一些,为什么项目中会出现大量的对象映射转换?(以下对于非MVC项目也适用) 在现代的软件开发中,项目的层级更加的细分,而不同层级之间对于对象的需求是有区别的,这就需要在不同层级间传递

升级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