自定义Queryable映射扩展解析及现代替代实现方案问询

一、工作原理 #

你写的这个QueryableMappingExtensions静态类，本质是对AutoMapper原生ProjectTo扩展的封装，核心逻辑完全依托AutoMapper的Queryable投影能力：

1. AutoMapper投影基础：AutoMapper的ProjectTo是专门针对IQueryable的扩展，它不会先把所有实体加载到内存再映射，而是将映射规则直接翻译成对应SQL，让数据库只返回目标ViewModel需要的字段，性能比内存映射高效得多。
2. 自定义重载的作用：你写的两个ProjectTo重载，核心是简化调用流程——比如可能一个重载自动获取IMapper实例或全局映射配置，不用每次调用都手动传入ConfigurationProvider。拿roomTypeService.GetRoomType<T>来说，当传入RoomTypeViewModel作为泛型参数时，扩展内部会：
   • 匹配AutoMapper中预先配置的RoomType到RoomTypeViewModel的映射规则（即你定义的CreateMap<RoomType, RoomTypeViewModel>）
   • 将IQueryable<RoomType>的查询表达式，转换为针对RoomTypeViewModel的投影表达式
   • 最终生成的SQL仅查询RoomTypeViewModel所需字段，执行后返回IQueryable<T>，可继续做分页、过滤或直接转为集合。

二、更简便的替代实现 #

其实完全没必要自定义扩展，AutoMapper原生的ProjectTo已经能满足需求，直接用原生方法更简洁，还能减少自定义代码的维护成本：

• 直接使用原生ProjectTo：在roomTypeService中注入IMapper后，直接编写代码：

  public IQueryable<RoomTypeViewModel> GetRoomType()
  {
      return _dbContext.RoomTypes.ProjectTo<RoomTypeViewModel>(_mapper.ConfigurationProvider);
  }
  

  如果需要泛型版本，直接给方法添加泛型参数即可：

  public IQueryable<T> GetRoomType<T>() where T : class
  {
      return _dbContext.RoomTypes.ProjectTo<T>(_mapper.ConfigurationProvider);
  }
  

• 避免过度封装：自定义扩展无非是省去每次传ConfigurationProvider的步骤，但依赖注入普及的当下，直接在服务中注入IMapper调用原生方法，代码更直观，也不容易出现配置偏差问题。

内容的提问来源于stack exchange，提问作者motaz allala