AutoMapper in ASP.NET Core

Introduction

AutoMapper maps ShopNest domain entities to API DTOs — reducing boilerplate while keeping layers separate. Know when manual mapping is simpler and when Mapster wins on performance.

After this article you will

• Configure profiles and AddAutoMapper
• Map entities to DTOs and reverse maps
• Use custom resolvers and ForMember
• Map collections and nested objects
• Test mappings with unit tests

Prerequisites

• Article 49 — Health Checks
• ShopNest API, EF Core, and DI from prior modules

Concept deep-dive

public class ProductProfile : Profile
{
    public ProductProfile()
    {
        CreateMap<Product, ProductListDto>()
            .ForMember(d => d.CategoryName,
                o => o.MapFrom(s => s.Category.Name));
        CreateMap<CreateProductDto, Product>()
            .ForMember(d => d.CreatedAt, o => o.MapFrom(_ => DateTime.UtcNow));
    }
}

// Usage
var dto = _mapper.Map<ProductDetailDto>(product);
var entities = _mapper.Map<List<ProductListDto>>(products);

Performance: AutoMapper reflection has cost — Mapster generates compile-time code. For hot paths, manual projection with Select() or Mapster may win.

Hands-on — ShopNest API with Complex Domain Models

1. ProductProfile in Application layer.
2. ProjectTo for IQueryable list queries (EF extension).
3. MappingTests assert CreateMap configuration valid.

Common errors & best practices

• Mapping in both directions blindly — overwrites IDs on update incorrectly.
• Lazy mapping huge graphs — project only needed fields.

Interview questions

Q: Why AutoMapper?
A: DRY for entity↔DTO when shapes differ slightly.

Q: AutoMapper slow?
A: Can be vs hand-written Select — profile and ProjectTo help; Mapster alternative.

Summary

• Profiles keep mapping rules centralized
• ProjectTo translates to SQL-friendly projections
• Validate configuration in CI with AssertConfigurationIsValid
• Use judiciously — simple maps can stay manual

Previous: Health Checks
Next: Microservices Introduction

FAQ