By the end of this session, you will be able to:

• Implement the repository pattern to abstract database access behind a clean interface
• Explain why exposing entity objects directly from an API is a security and stability risk
• Define request and response DTOs and map between entities and DTOs using AutoMapper
• Prevent over-posting attacks by controlling which fields clients are allowed to submit

• Leaking infrastructure into business logic — when a service calls _context.Tasks.Where(...).ToListAsync(), the EF Core query language bleeds into a layer that should only care about business rules
• Hard to test — spinning up a real DbContext in a unit test requires a database. With an interface you swap in a mock that returns fake data instantly
• Hard to change the database — if you ever move from SQL Server to PostgreSQL or a document store, every service that calls DbContext must be rewritten
• No single place for query logic — the same Where(t => t.UserId == userId) filter gets duplicated across multiple services and controllers
• Violates the Dependency Inversion Principle — high-level modules (services) should depend on abstractions, not on concrete infrastructure classes

public interface ITaskRepository
{
    Task<TaskItem?> GetByIdAsync(int id);
    Task<PagedResult<TaskItem>> GetAllAsync(TaskFilterParams filter);
    Task<TaskItem> CreateAsync(TaskItem task);
    Task UpdateAsync(TaskItem task);
    Task DeleteAsync(TaskItem task);
}

public class TaskRepository : ITaskRepository
{
    private readonly AppDbContext _context;
    public TaskRepository(AppDbContext context) => _context = context;

    public async Task<TaskItem?> GetByIdAsync(int id)
        => await _context.Tasks.FindAsync(id);

    public async Task<TaskItem> CreateAsync(TaskItem task)
    {
        _context.Tasks.Add(task);
        await _context.SaveChangesAsync();
        return task;
    }

    public async Task UpdateAsync(TaskItem task)
    {
        _context.Tasks.Update(task);
        await _context.SaveChangesAsync();
    }

    public async Task DeleteAsync(TaskItem task)
    {
        _context.Tasks.Remove(task);
        await _context.SaveChangesAsync();
    }
}

public class TaskItemDto
{
    public int Id { get; set; }
    public string Title { get; set; } = "";
    public string? Description { get; set; }
    public bool IsCompleted { get; set; }
    public DateTime? DueDate { get; set; }
    public DateTime CreatedAt { get; set; }
}

Compare this to the entity: UserId, internal foreign keys, and navigation properties are absent. Clients receive exactly what they need to display a task — nothing they could misuse.

dotnet add package AutoMapper

public class MappingProfile : Profile
{
    public MappingProfile()
    {
        // Entity -> Response DTO (property names match — no extra config needed)
        CreateMap<TaskItem, TaskItemDto>();

        // Request DTO -> Entity (set server-controlled fields explicitly)
        CreateMap<CreateTaskRequest, TaskItem>()
            .ForMember(dest => dest.CreatedAt,
                       opt  => opt.MapFrom(_ => DateTime.UtcNow));
    }
}

ForMember lets you override how a single destination property is filled. Here CreatedAt is always set to the server's current UTC time — the client cannot influence it even if they send a value.

public async Task<TaskItemDto> CreateAsync(CreateTaskRequest request)
{
    // Map request DTO -> entity (AutoMapper sets CreatedAt via ForMember)
    var task = _mapper.Map<TaskItem>(request);

    // Persist via repository (no DbContext in sight)
    var created = await _repo.CreateAsync(task);

    // Map entity -> response DTO (sensitive fields absent by design)
    return _mapper.Map<TaskItemDto>(created);
}

Notice the three layers are cleanly separated: the request DTO enters, the entity is persisted through the repository, and the response DTO exits. No DbContext, no raw entity, no sensitive fields reach the controller.

Refactor the Task API to use the repository pattern and DTOs throughout. Each step builds on the last — complete them in order.

• The repository pattern places an interface between the service layer and the database — services depend on ITaskRepository, not on DbContext, making the data layer swappable and testable
• Register repositories as Scoped to match the lifetime of the DbContext they wrap — one instance per HTTP request
• Response DTOs expose only what the consumer legitimately needs — fields like password hashes and refresh tokens are absent by design, not by annotation
• Request DTOs prevent over-posting — server-controlled fields such as Id, CreatedAt, and role flags are simply not present in the request model
• AutoMapper eliminates hand-copying — declare mappings once in a Profile class and call _mapper.Map<T>(source) everywhere
• Use ForMember whenever a server-controlled value (such as DateTime.UtcNow) must be set during mapping rather than read from the incoming request

Session 12 — Input Validation

• The request DTOs you defined today accept any string for Title — Session 12 covers how to enforce rules on those inputs using Data Annotations and FluentValidation
• You will learn how ASP.NET Core's model validation pipeline automatically rejects malformed requests before they reach your service layer, and how to return structured validation error responses
• The CreateTaskRequest and UpdateTaskRequest DTOs you built today will be the targets for the validation rules added in Session 12
• After Session 12 the complete data flow — validated request DTO in, repository operation, response DTO out — will be fully hardened

Refactor the Task Manager API to use the repository pattern and DTOs throughout.

What to build:

• Create ITaskRepository and TaskRepository, register the repository as Scoped in Program.cs
• Define TaskItemDto, CreateTaskRequest, and UpdateTaskRequest with appropriate fields
• Write a MappingProfile that maps all three pairs; set CreatedAt via ForMember during the create mapping
• Update TaskService to depend on ITaskRepository and IMapper — all controller actions must return DTOs, not entities

Acceptance criteria:

• GET /api/tasks/{id} returns a TaskItemDto — no entity navigation properties, no sensitive fields in the response body
• POST /api/tasks accepts a CreateTaskRequest body; sending extra fields like id or createdAt has no effect on the created record
• TaskService has zero references to AppDbContext — all database access goes through ITaskRepository
• MappingProfile is the only place where field assignments between entities and DTOs are defined