上篇随笔写的是我们在新版博客后台开发中用上了新式武器——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
【编辑推荐】
