Repositórios Genéricos

Repositórios Genéricos no Repository Pattern

Introdução aos Repositórios Genéricos

Com os fundamentos do Repository Pattern estabelecidos, avança-se para um tópico mais avançado: os repositórios genéricos. Esta abordagem, embora popular em determinados contextos, apresenta considerações arquiteturais importantes que devem ser ponderadas antes de sua adoção.

A implementação de um repositório genérico visa criar uma classe base que encapsule operações CRUD comuns, permitindo que repositórios específicos herdem essa funcionalidade. Contudo, esta estratégia nem sempre se alinha com práticas de design como Domain-Driven Design (DDD) ou Arquitetura Limpa, onde as operações de acesso a dados frequentemente possuem requisitos específicos do domínio.

Design da Interface Genérica

Princípio de Segregação de Interface (ISP)

Ao definir uma interface de repositório genérico, é essencial considerar o Princípio de Segregação de Interface (Interface Segregation Principle - ISP) dos princípios SOLID. Este princípio estabelece que uma interface não deve forçar suas implementadoras a depender de métodos que não utilizam.

Uma interface genérica IRepository que define um CRUD completo obrigaria todas as entidades do sistema a implementar todas as operações, mesmo quando algumas delas não são necessárias para determinado domínio.

namespace RepositoryStore.Repositories.Abstractions;

// Implementação inicial - potencial violação do ISP
public interface IRepository<T> where T : class
{
    Task<T> CreateAsync(T entity, CancellationToken cancellationToken = default);
    Task<T> UpdateAsync(T entity, CancellationToken cancellationToken = default);
    Task<T> DeleteAsync(T entity, CancellationToken cancellationToken = default);
    Task<T?> GetByIdAsync(int id, CancellationToken cancellationToken = default);
    Task<List<T>> GetAllAsync(int skip = 0, int take = 25, 
        CancellationToken cancellationToken = default);
}

Consideração arquitetural: Em sistemas que seguem rigorosamente o ISP, poderiam ser definidas interfaces separadas:

public interface IReadRepository<T> where T : class
{
    Task<T?> GetByIdAsync(int id, CancellationToken cancellationToken = default);
    Task<List<T>> GetAllAsync(int skip = 0, int take = 25, 
        CancellationToken cancellationToken = default);
}

public interface IWriteRepository<T> where T : class
{
    Task<T> CreateAsync(T entity, CancellationToken cancellationToken = default);
    Task<T> UpdateAsync(T entity, CancellationToken cancellationToken = default);
    Task<T> DeleteAsync(T entity, CancellationToken cancellationToken = default);
}

Modelagem com Entidade Base

Para sistemas que utilizam uma hierarquia de entidades, pode-se definir uma classe base abstrata:

namespace RepositoryStore.Models;

public abstract class Entity
{
    public int Id { get; protected set; }
    public DateTime CreatedAt { get; protected set; } = DateTime.UtcNow;
    public DateTime? UpdatedAt { get; protected set; }
}

A interface genérica pode então restringir o tipo T para derivados de Entity:

using RepositoryStore.Models;

namespace RepositoryStore.Repositories.Abstractions;

public interface IRepository<T> where T : Entity
{
    Task<T> CreateAsync(T entity, CancellationToken cancellationToken = default);
    Task<T> UpdateAsync(T entity, CancellationToken cancellationToken = default);
    Task<T> DeleteAsync(T entity, CancellationToken cancellationToken = default);
    Task<T?> GetByIdAsync(int id, CancellationToken cancellationToken = default);
    Task<List<T>> GetAllAsync(int skip = 0, int take = 25, 
        CancellationToken cancellationToken = default);
}

Para fins demonstrativos, manteremos a restrição where T : class por ser mais genérica e aplicável a diferentes cenários.

Refatorando as Interfaces Específicas

Com a interface genérica definida, as interfaces específicas podem ser simplificadas. A interface IProductRepository passa a herdar da interface genérica, especificando o tipo concreto:

using RepositoryStore.Models;

namespace RepositoryStore.Repositories.Abstractions;

// Versão simplificada herdando da interface genérica
public interface IProductRepository : IRepository<Product>
{
    // Métodos específicos de Product podem ser adicionados aqui
    // Exemplo: Task<List<Product>> GetByCategoryAsync(int categoryId, ...);
}

Observação: Em versões mais recentes do C# (12+), a sintaxe pode ser ainda mais concisa:

public interface IProductRepository : IRepository<Product>;

Esta abordagem mantém a flexibilidade para adicionar métodos específicos do domínio quando necessário, enquanto herda automaticamente todas as operações CRUD definidas na interface genérica.

Implementação da Classe Base Genérica

Estrutura da Classe Abstrata

Cria-se uma classe abstrata Repository<T> que implementa a interface IRepository<T>:

using Microsoft.EntityFrameworkCore;
using RepositoryStore.Repositories.Abstractions;

namespace RepositoryStore.Repositories;

public abstract class Repository<T>(DbContext context) 
    : IRepository<T> where T : class
{
    private readonly DbSet<T> _dbSet = context.Set<T>();
    protected readonly DbContext Context = context;
    
    // Implementações dos métodos serão adicionadas aqui
}

Análise da estrutura:

• A classe é declarada como abstract para prevenir instanciação direta

• O construtor primário recebe DbContext (não AppDbContext) para maior reutilização

• A propriedade _dbSet é inicializada usando context.Set<T>(), que obtém o DbSet<T> apropriado para a entidade genérica

• O DbContext é armazenado em campo protegido para uso nas operações de persistência

Obtendo o DbSet Genérico

O método context.Set<T>() é uma funcionalidade fundamental do Entity Framework que retorna a instância de DbSet<T> correspondente à entidade T. Este mecanismo permite que a classe base opere com qualquer entidade mapeada no contexto, sem precisar conhecer especificamente qual DbSet utilizar.

Implementação das Operações CRUD

public async Task<T> CreateAsync(T entity, CancellationToken cancellationToken = default)
{
    // Adiciona a entidade ao DbSet correspondente
    await _dbSet.AddAsync(entity, cancellationToken);
    
    // Persiste todas as mudanças pendentes no contexto
    await Context.SaveChangesAsync(cancellationToken);
    
    // Retorna a entidade (agora com IDs gerados, se aplicável)
    return entity;
}

public async Task<T> UpdateAsync(T entity, CancellationToken cancellationToken = default)
{
    // Marca a entidade como modificada
    _dbSet.Update(entity);
    
    // Persiste a alteração
    await Context.SaveChangesAsync(cancellationToken);
    
    return entity;
}

public async Task<T> DeleteAsync(T entity, CancellationToken cancellationToken = default)
{
    // Remove a entidade do DbSet
    _dbSet.Remove(entity);
    
    // Persiste a exclusão
    await Context.SaveChangesAsync(cancellationToken);
    
    // Retorna a entidade excluída (para confirmação)
    return entity;
}

public async Task<T?> GetByIdAsync(int id, CancellationToken cancellationToken = default)
{
    // FindAsync é otimizado para busca por chave primária
    return await _dbSet.FindAsync([id], cancellationToken);
}

public async Task<List<T>> GetAllAsync(
    int skip = 0, 
    int take = 25, 
    CancellationToken cancellationToken = default)
{
    // Consulta com paginação e sem tracking para melhor performance
    return await _dbSet
        .AsNoTracking() // Desabilita tracking para operações somente leitura
        .Skip(skip)
        .Take(take)
        .ToListAsync(cancellationToken);
}

Implementação Completa da Classe Base

using Microsoft.EntityFrameworkCore;
using RepositoryStore.Repositories.Abstractions;

namespace RepositoryStore.Repositories;

public abstract class Repository<T>(DbContext context) 
    : IRepository<T> where T : class
{
    private readonly DbSet<T> _dbSet = context.Set<T>();
    protected readonly DbContext Context = context;
    
    public async Task<T> CreateAsync(T entity, CancellationToken cancellationToken = default)
    {
        await _dbSet.AddAsync(entity, cancellationToken);
        await Context.SaveChangesAsync(cancellationToken);
        return entity;
    }

    public async Task<T> UpdateAsync(T entity, CancellationToken cancellationToken = default)
    {
        _dbSet.Update(entity);
        await Context.SaveChangesAsync(cancellationToken);
        return entity;
    }

    public async Task<T> DeleteAsync(T entity, CancellationToken cancellationToken = default)
    {
        _dbSet.Remove(entity);
        await Context.SaveChangesAsync(cancellationToken);
        return entity;
    }

    public async Task<T?> GetByIdAsync(int id, CancellationToken cancellationToken = default)
        => await _dbSet.FindAsync([id], cancellationToken);

    public async Task<List<T>> GetAllAsync(
        int skip = 0, 
        int take = 25, 
        CancellationToken cancellationToken = default)
        => await _dbSet
            .AsNoTracking()
            .Skip(skip)
            .Take(take)
            .ToListAsync(cancellationToken);
}

Refatorando os Repositórios Específicos

Com a classe base implementada, os repositórios específicos tornam-se extremamente concisos:

Repositório de Produtos

using RepositoryStore.Data;
using RepositoryStore.Models;
using RepositoryStore.Repositories.Abstractions;

namespace RepositoryStore.Repositories;

public class ProductRepository(AppDbContext context) 
    : Repository<Product>(context), IProductRepository
{
    // Métodos específicos de Product podem ser adicionados aqui
    // Exemplo:
    // public async Task<List<Product>> GetExpensiveProductsAsync(decimal minPrice, ...)
    // {
    //     return await _dbSet
    //         .Where(p => p.Price > minPrice)
    //         .ToListAsync();
    // }
}

Versão concisa (C# 12+):

public class ProductRepository(AppDbContext context) 
    : Repository<Product>(context), IProductRepository;

Repositório de Categorias

public class CategoryRepository(AppDbContext context) 
    : Repository<Category>(context), ICategoryRepository;

Repositório de Usuários

public class UserRepository(AppDbContext context) 
    : Repository<User>(context), IUserRepository;

Manutenção da Configuração de Dependência

Um dos benefícios significativos desta abordagem é que a configuração de injeção de dependência no Program.cs permanece inalterada:

// Configuração original mantida
builder.Services.AddTransient<IProductRepository, ProductRepository>();

Os consumidores da interface IProductRepository continuam funcionando normalmente, sem necessidade de alterações, demonstrando a compatibilidade retroativa da refatoração.

Vantagens e Desvantagens

Vantagens dos Repositórios Genéricos

1. Redução de Código Duplicado: Operações CRUD comuns são implementadas uma única vez

2. Consistência: Garante padrão uniforme em todas as operações de persistência

3. Manutenibilidade Simplificada: Correções e melhorias aplicam-se automaticamente a todos os repositórios

4. Velocidade de Desenvolvimento: Novas entidades podem ter repositórios funcionais com mínimo esforço

5. Curva de Aprendizado: Desenvolvedores novos compreendem rapidamente o padrão estabelecido

Desvantagens e Considerações Críticas

1. Potencial Violação do ISP: Entidades podem ser forçadas a implementar operações não utilizadas

2. Limitação em Consultas Complexas: Consultas específicas do domínio frequentemente exigem métodos adicionais

3. Acoplamento ao Entity Framework: A implementação genérica está intimamente ligada ao EF Core

4. Dificuldade com Agregados Complexos: Em DDD, agregados com múltiplas entidades podem não se adequar ao modelo genérico

5. Falta de Especificidade do Domínio: Operações de negócio específicas ficam fora do escopo do repositório genérico

Casos de Uso Recomendados

• Sistemas CRUD Simples: Aplicações com operações básicas de persistência

• Prototipagem Rápida: Desenvolvimento inicial onde a agilidade é prioritária

• APIs Administrativas: Interfaces onde operações genéricas são predominantes

• Sistemas com Muitas Entidades Similares: Domínios com múltiplas entidades que compartilham comportamento idêntico

Casos onde Evitar

• Sistemas com Lógica de Domínio Complexa: Onde cada entidade tem comportamentos únicos

• Arquitetura Limpa/DDD Rigorosa: Onde cada agregado tem requisitos específicos de persistência

• Consultas Otimizadas para Performance: Onde consultas personalizadas são necessárias

• Sistemas com Múltiplas Fontes de Dados: Onde diferentes entidades podem usar diferentes estratégias de persistência

Extensões e Personalizações

Adicionando Métodos Específicos

Mesmo com a classe base genérica, repositórios específicos podem estender a funcionalidade:

public class ProductRepository(AppDbContext context) 
    : Repository<Product>(context), IProductRepository
{
    public async Task<List<Product>> GetByCategoryAsync(
        int categoryId, 
        CancellationToken cancellationToken = default)
    {
        // Acesso ao DbSet através do campo protegido na classe base
        return await _dbSet
            .Where(p => p.CategoryId == categoryId)
            .ToListAsync(cancellationToken);
    }
    
    public async Task<List<Product>> SearchByNameAsync(
        string searchTerm,
        CancellationToken cancellationToken = default)
    {
        return await _dbSet
            .Where(p => p.Name.Contains(searchTerm))
            .ToListAsync(cancellationToken);
    }
}

Implementando Interfaces Adicionais

Para maior flexibilidade, podem ser definidas múltiplas interfaces:

public interface ISearchableRepository<T> where T : class
{
    Task<List<T>> SearchAsync(string term, CancellationToken cancellationToken = default);
}

public class ProductRepository(AppDbContext context) 
    : Repository<Product>(context), 
      IProductRepository,
      ISearchableRepository<Product>
{
    public async Task<List<Product>> SearchAsync(
        string term, 
        CancellationToken cancellationToken = default)
    {
        return await _dbSet
            .Where(p => p.Name.Contains(term) || p.Description.Contains(term))
            .ToListAsync(cancellationToken);
    }
}

Conclusão e Recomendações Práticas

A implementação de repositórios genéricos representa uma ferramenta poderosa no arsenal do desenvolvedor, mas sua adoção deve ser ponderada em relação aos requisitos específicos do projeto.

Diretrizes de Decisão

1. Avaliar a Complexidade do Domínio: Sistemas com regras de negócio simples beneficiam-se mais da genericidade

2. Considerar a Evolução do Sistema: Prever se operações específicas serão necessárias no futuro

3. Analisar os Requisitos de Performance: Consultas genéricas podem não ser otimizadas para cenários específicos

4. Manter a Flexibilidade Arquitetural: Garantir que a solução não comprometa princípios de design importantes

Melhores Práticas Identificadas

1. Começar com Especificidade: Iniciar com repositórios específicos e extrair padrões comuns posteriormente

2. Manter a Capacidade de Extensão: Projetar a classe base para permitir sobrescrita de métodos quando necessário

3. Documentar Suposições e Limitações: Clarificar os cenários onde a solução genérica é apropriada

4. Implementar Progressivamente: Adicionar genericidade gradualmente à medida que os padrões emergem

Alternativas Consideradas

• Repositórios Específicos por Entidade: Máximo controle e especificidade, com custo de duplicação

• Padrão Specification: Separação das regras de consulta dos repositórios

• Query Objects: Encapsulamento de consultas complexas em objetos especializados

• CQRS (Command Query Responsibility Segregation): Separação radical entre operações de leitura e escrita

A decisão final deve equilibrar os benefícios da reutilização de código com a necessidade de expressar adequadamente a lógica de domínio e atender aos requisitos específicos do sistema em desenvolvimento. A implementação apresentada serve como base sólida que pode ser adaptada conforme as necessidades do projeto evoluem.