如何在通用仓储中使用AutoMapper投影避免循环引用？

嘿，我完全懂你现在的困扰——刚切换到通用仓储+工作单元模式，结果之前顺手的AutoMapper ProjectTo 方法突然不好使了，还要处理关联数据带来的循环引用问题，尤其是给Kendo UI Grid返回数据的时候，简直头大对吧？别慌，咱们一步步拆解解决：

1. 先确认通用仓储返回的是IQueryable<T> #

ProjectTo 是依赖IQueryable来实现数据库层面投影的，如果你的仓储返回的是List<T>或者IEnumerable<T>（已经在内存中执行了查询），那ProjectTo不仅没法发挥性能优势，还可能因为实体的导航属性引发循环引用。

修正方案：确保仓储的查询方法返回IQueryable<T>，比如：

public class GenericRepository<TEntity> : IGenericRepository<TEntity> where TEntity : class
{
    private readonly DbSet<TEntity> _dbSet;

    public GenericRepository(AppDbContext context)
    {
        _dbSet = context.Set<TEntity>();
    }

    // 关键：返回IQueryable，不要提前执行ToList()
    public IQueryable<TEntity> GetAll(bool asNoTracking = true)
    {
        return asNoTracking ? _dbSet.AsNoTracking() : _dbSet;
    }
}

AsNoTracking还能提升查询性能，同时避免实体跟踪带来的额外问题，非常适合只读的列表查询场景。

2. 调整AutoMapper配置，处理循环引用 #

循环引用大多是因为实体间的双向导航属性（比如Order包含Customer，Customer又包含List<Order>），在映射到ViewModel时必须明确处理：

方案一：忽略引发循环的属性
在AutoMapper配置中，直接忽略ViewModel不需要的循环导航属性：

CreateMap<Order, OrderViewModel>()
    .ForMember(dest => dest.CustomerInfo, opt => opt.MapFrom(src => src.Customer))
    // 忽略Customer里的Orders集合，切断循环
    .ForMember(dest => dest.CustomerInfo.Orders, opt => opt.Ignore());

// 或者更干脆，在Customer的ViewModel里就不定义Orders属性
CreateMap<Customer, CustomerViewModel>()
    .ForMember(dest => dest.Id, opt => opt.MapFrom(src => src.Id))
    .ForMember(dest => dest.Name, opt => opt.MapFrom(src => src.Name));

方案二：使用MaxDepth限制映射深度
如果需要保留部分嵌套属性但不想循环，可以设置最大映射深度：

CreateMap<Order, OrderViewModel>()
    .MaxDepth(2); // 只映射两层嵌套，避免无限循环

3. 结合工作单元的正确调用姿势 #

在控制器或服务中，要确保先拿到仓储的IQueryable，再调用ProjectTo，最后执行查询（比如给Kendo Grid返回结果）：

public class OrderController : Controller
{
    private readonly IUnitOfWork _unitOfWork;
    private readonly IMapper _mapper;

    public OrderController(IUnitOfWork unitOfWork, IMapper mapper)
    {
        _unitOfWork = unitOfWork;
        _mapper = mapper;
    }

    public ActionResult GetOrders([DataSourceRequest] DataSourceRequest request)
    {
        // 1. 从仓储获取IQueryable
        var orderQuery = _unitOfWork.OrderRepository.GetAll();
        
        // 2. 直接在IQueryable上执行ProjectTo投影
        var viewModelQuery = orderQuery.ProjectTo<OrderViewModel>(_mapper.ConfigurationProvider);
        
        // 3. 结合Kendo的ToDataSourceResult处理分页/排序/过滤
        var result = viewModelQuery.ToDataSourceResult(request);
        
        return Json(result);
    }
}

这里要注意：必须保证工作单元的生命周期覆盖整个查询过程（比如在ASP.NET MVC中，工作单元通常按请求生命周期注入，这点没问题）。

4. 排查是否提前执行了查询 #

如果你的通用仓储在内部做了ToList()或者FirstOrDefault()这类立即执行的操作，那ProjectTo就失去了作用。一定要检查仓储方法，确保返回的是未执行的IQueryable，直到最后一步（比如ToDataSourceResult或ToList()）才触发数据库查询。

核心思路就是：保留IQueryable的延迟执行特性，让AutoMapper在数据库层面完成投影，同时通过AutoMapper配置切断循环引用，最后结合Kendo的方法处理前端需要的分页排序逻辑。这样既解决了ProjectTo失效的问题，又能避免循环引用导致的序列化错误。

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