博客园现代化建设——AutoMapper

博客园现代化建设——AutoMapper

上篇随笔写的是我们在新版博客后台开发中用上了新式武器——Entity Framework,该武器火力猛,威力大,但使用中发现在某些场景下显得不够灵活,后来不得不引进轻量级常规武器——AutoMapper

我们遇到的场景是一个复杂的实体类,有很多属性,数据库操作是一个跨数据库查询,查询的字段远远少于实体类的属性。

对于跨数据库查询,我们没有找到通过LINQ to Entities实现的方法,于是就用DbSet.SqlQuery调用存储过程进行查询,代码如下:

    
      
using (BlogDbContext context = new BlogDbContext())
{
string sql = string .Format( " EXEC [blog_Entry_Get] @BlogID={0},@EntryID={1} " , blogId, entryId);
BlogEntry entry
= context.BlogEntries.SqlQuery(sql).Single();
}

虽然不能使用LINQ进行查询,但我们不想在这里抛弃这个新式武器,不能发射导弹,可以用一下机关枪嘛。于是,如上面的代码所示,用SqlQuery进行查询,用Entity Framework完成查询结果与实体类的数据映射。

结果发现,Entity Framework是依赖于实体类的属性进行映射的。如果把Entity Framework比作机关枪,那实体类的属性就是子弹,每颗子弹只能攻击唯一对应的目标,在射击过程中,只要有一颗子弹攻击的目标不存在,机枪就会卡壳(子弹决定目标?)。也就是Entity Framework会在IDataReader中查找每个实体类属性对应的值,而我们的应用场景却是“查询的字段远远少于实体类的属性”,这时,Entity Framework成为了一堆废铁(这个说法不妥,可以通过modelBuilder.Entity<BlogEntry>().Ignor忽略不需要映射的字段,但是,如果不同的查询返回的字段不同,这个方法就不管用了)。

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

翻来覆去地摆弄它,还是没搞定,只能换武器...

数据库查询换成了旧式武器Enterprise Library,并引进了新的轻量级常规武器AutoMapper进行查询结果与实体类的映射(而且是开源的)。

“轻量级”果然名不虚转,简单易用,针对性强,我们用它轻松解决了问题,代码如下:

复制代码
    
      
SqlCommand command = (SqlCommand)_sqldb.GetStoredProcCommand( " [blog_Entry_Get] " );
command.Parameters.AddWithValue(
" @BlogID " , blogId);
command.Parameters.AddWithValue(
" @EntryID " , entryId);
using (IDataReader reader = _sqldb.ExecuteReader(command))
{
if (reader.Read())
{
BlogEntry entry
= AutoMapper.Mapper.DynamicMap < BlogEntry > (reader);
}
}
复制代码
原文地址:http://www.cnblogs.com/dudu/archive/2011/03/28/entity_framework_automapper.html

你可能感兴趣的:(mapper)