Mudanças no EF Core 5 que todos aguardamos

O que é um ORM

Antes de falar das novidades, vale pontuar o que de fato é um ORM. ORM é a sigla para Object/Relational Mapping, ou seja, mapeamento objeto/relacional.

A função dele é mapear o resultado que recebemos de um banco de dados relacional para um objeto. Note que eu disse objeto e não entidade, porque o destino pode ser um DTO, uma entidade anêmica ou qualquer outra classe.

Em outras palavras, o ORM traduz linhas e colunas em instâncias de classes e faz o caminho inverso na hora de salvar. Com isso, você escreve LINQ em vez de SQL na maior parte do tempo.

Caso queira saber mais sobre modelagem de domínios ricos, acesse meu curso gratuito sobre o assunto clicando aqui.

A trajetória do Entity Framework Core

Na versão 1.x do .NET Core, muita coisa foi prometida. Contudo, como as mudanças eram muitas, minha expectativa não estava lá em cima, pois eu sabia que o .NET Core ainda não estava maduro e o EF Core muito menos.

O item que mais me deixou desapontado foi o mapeamento NxN. Antes, no Entity Framework 6, ele funcionava com navigation properties nas duas pontas, mas no EF Core passou a exigir uma classe exclusiva para a tabela de junção.

Em termos de modelagem, isso é muito ruim. Sabemos que não conseguimos ter o cenário perfeito de orientação a objetos usando um ORM, mas afetar dessa forma a modelagem chega a doer na alma.

Na versão 2.x vieram várias melhorias de performance e de consultas. Na 3.x, o time reescreveu a tradução de queries, mas nada do NxN mudar.

A proposta do EF Core: data driven ou domain driven

Foi então que decidi parar de brigar e assumir que a proposta do EF Core é mais data driven do que domain driven. Olhando o cenário NxN, vemos claramente uma alusão aos relacionamentos de bancos de dados, e não à orientação a objetos.

Encarar dessa forma facilitou encaixar o uso do EF Core no dia a dia. Em cenários data driven ele brilha, enquanto em cenários focados em domínios ricos ou usamos outra ferramenta ou desmanchamos nossas entidades.

Por exemplo, muita gente combina o EF Core para escrita com o Dapper para leitura. Esse equilíbrio aparece no artigo Dapper e Entity Framework Core, que compara as duas abordagens.

Se quiser saber mais sobre a criação de APIs data driven com ASP.NET Core 3 e EF Core 3, acesse meu curso clicando aqui.

A comunidade e o planejamento do EF Core 5

Outro ponto que me incomodava bastante é que muitas das features abaixo estavam como sugestão no GitHub do EF Core havia tempos. Mesmo assim, elas vinham ficando de fora das versões.

Não estou julgando, pois não sei como as coisas acontecem internamente. No entanto, a implementação dessas features no EF Core 5 mostra que o time passou a se posicionar de forma diferente, ouvindo mais a comunidade.

Os números do próprio plano oficial do EF Core 5.0 confirmam isso. O many-to-many era a feature mais votada do backlog, com cerca de 506 votos, o filtered include vinha em segundo, com cerca de 376, e o TPT em terceiro, com cerca de 289.

Ou seja, as três maiores demandas da comunidade entraram no EF Core 5. Além disso, o processo de planejamento da Microsoft passou a deixar claro que os votos nas issues do GitHub pesam nas decisões.

Mudanças no EF Core 5

A primeira mudança está na própria versão. Não existe EF Core 4.x, porque o time pulou direto para o EF Core 5 para acompanhar o .NET 5.

Além disso, o EF Core 5 roda em qualquer plataforma compatível com o .NET Standard 2.1, incluindo o .NET 5. Por outro lado, ele não roda no .NET Framework, o que encerra de vez essa compatibilidade.

Embora a mudança seja grande, o time prometeu breaking changes bem menos severas que as do EF Core 3.0. A meta declarada era permitir que a grande maioria das aplicações atualizasse sem quebrar.

Sem mais delongas, vamos às seis mudanças mais aguardadas no Entity Framework Core 5.

public class Post
{
    public int Id { get; set; }
    public string Title { get; set; }

    // Coleção de tags, sem classe de junção
    public ICollection<Tag> Tags { get; set; }
}

public class Tag
{
    public int Id { get; set; }
    public string Name { get; set; }

    // Coleção inversa, fecha o relacionamento NxN
    public ICollection<Post> Posts { get; set; }
}

public abstract class Payment
{
    public int Id { get; set; }
    public decimal Amount { get; set; }
}

public class CreditCardPayment : Payment
{
    public string CardHolder { get; set; }
}

public class BankSlipPayment : Payment
{
    public string BarCode { get; set; }
}

public class StoreContext : DbContext
{
    public DbSet<Payment> Payments { get; set; }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // Cada tipo da hierarquia vira uma tabela
        modelBuilder.Entity<CreditCardPayment>().ToTable("CreditCardPayments");
        modelBuilder.Entity<BankSlipPayment>().ToTable("BankSlipPayments");
    }
}

// Traz os blogs e apenas os posts publicados, ordenados e limitados
var blogs = await context.Blogs
    .Include(blog => blog.Posts
        .Where(post => post.IsPublished)
        .OrderByDescending(post => post.PublishedAt)
        .Take(5))
    .ToListAsync();

// Divide a consulta em vários comandos SQL, um por coleção
var orders = await context.Orders
    .Include(order => order.Items)
    .Include(order => order.Payments)
    .AsSplitQuery()
    .ToListAsync();

# Lista as migrations e mostra quais ainda não foram aplicadas
dotnet ef migrations list

# Aplica as migrations informando a connection string na linha de comando
dotnet ef database update --connection "Server=localhost;Database=Store;Trusted_Connection=True"

# Gera um script SQL idempotente para rodar no pipeline
dotnet ef migrations script --idempotent --output migrate.sql

// Registra a fábrica de contextos no container de DI
services.AddDbContextFactory<StoreContext>(options =>
    options.UseSqlServer(connectionString));

public class ProductService
{
    private readonly IDbContextFactory<StoreContext> _contextFactory;

    public ProductService(IDbContextFactory<StoreContext> contextFactory)
        => _contextFactory = contextFactory;

    public async Task<int> CountProductsAsync()
    {
        // Cada operação usa um contexto novo e descartável
        using var context = _contextFactory.CreateDbContext();
        return await context.Products.CountAsync();
    }
}

Outras novidades que chegaram com o EF Core 5

Além das seis mudanças acima, a versão final trouxe recursos que não estavam no centro do plano. Vários deles mudam o dia a dia de quem depura consultas.

O primeiro é o LogTo, uma forma simples de configurar logs. Em seguida vem o ToQueryString, que devolve o SQL que uma consulta LINQ vai executar.

public class StoreContext : DbContext
{
    public DbSet<Product> Products { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        => optionsBuilder
            .UseSqlServer("Server=localhost;Database=Store;Trusted_Connection=True")
            // Escreve no console todos os logs, incluindo o SQL gerado
            .LogTo(Console.WriteLine);
}

// Mostra o SQL sem executar a consulta
var sql = context.Products
    .Where(product => product.Price > 100)
    .ToQueryString();

Console.WriteLine(sql);

Outra novidade são os dependentes obrigatórios em relacionamentos um para um. No EF Core 3.1, todo owned type era opcional, e suas colunas eram criadas como anuláveis no banco.

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Customer>(builder =>
    {
        builder.OwnsOne(customer => customer.Address, address =>
        {
            address.Property(a => a.Street).IsRequired();
            address.Property(a => a.ZipCode).IsRequired();
        });

        // O endereço passa a ser obrigatório no modelo
        builder.Navigation(customer => customer.Address).IsRequired();
    });
}

Também chegaram as collations por coluna, os atributos [Index] e [Keyless], a configuração de precisão e escala pela Fluent API e o ChangeTracker.Clear. No SQLite, o EF Core 5 passou a reconstruir tabelas automaticamente para suportar operações de migração antes impossíveis, como remover colunas.

Por fim, o mapeamento ficou mais flexível. Agora uma entidade pode apontar para uma view na leitura e para uma tabela na escrita, ou ainda para uma função com valor de tabela.

Como atualizar um projeto para o EF Core 5

Se você tem um projeto em EF Core 3.1, o primeiro passo é conferir o target framework. Como o EF Core 5 exige .NET Standard 2.1, o projeto precisa estar no .NET Core 3.x ou no .NET 5.

Em seguida, atualize os pacotes do provedor e das ferramentas para a mesma versão.

# Atualiza o provedor do SQL Server
dotnet add package Microsoft.EntityFrameworkCore.SqlServer --version 5.0.0

# Atualiza o pacote de design usado pelas migrations
dotnet add package Microsoft.EntityFrameworkCore.Design --version 5.0.0

# Atualiza a ferramenta de linha de comando
dotnet tool update --global dotnet-ef --version 5.0.0

Depois, leia a lista oficial de breaking changes e rode a suíte de testes completa. Uma mudança comum, por exemplo, é o scaffolding singularizar nomes de tabelas, gerando Person a partir de People.

Vale lembrar que o suporte ao EF Core 5 terminou em 10 de maio de 2022, junto com o do .NET 5. Portanto, este conteúdo serve para entender a evolução do framework e para manter sistemas legados, enquanto projetos novos devem usar uma versão suportada.

Se você acompanhou a fase de prévia, o artigo sobre o Entity Framework Core 5 Preview 1 mostra como essas features começaram a aparecer.

Conclusão

O EF Core 5 respondeu às maiores demandas da comunidade. O many-to-many sem classe de junção, o TPT e o filtered include eram, nessa ordem, as três features mais votadas do backlog.

Além disso, as split queries corrigiram a principal regressão de performance do EF Core 3.0, e o LogTo com o ToQueryString simplificou a depuração. Já as migrations fora do startup avançaram em partes, com os bundles chegando só na versão seguinte.

Na minha visão, o EF Core 5 continua sendo um ORM mais data driven do que domain driven. Ainda assim, a volta das navigation properties no NxN aproxima bastante o modelo da orientação a objetos.

Em resumo, o time mostrou que passou a ouvir a comunidade. E isso, para quem usa o framework no dia a dia, vale tanto quanto qualquer feature nova.

FAQ

Por que não existe EF Core 4?

O time pulou a versão 4 para alinhar a numeração ao .NET 5. Dessa forma, EF Core 5 e .NET 5 foram lançados juntos.

O EF Core 5 roda no .NET Framework?

Não. Ele exige uma plataforma compatível com .NET Standard 2.1, como o .NET Core 3.x ou o .NET 5.

Preciso apagar minha classe de junção para usar o many-to-many?

Não. O modelo com classe de junção explícita continua suportado, e a nova abordagem com duas coleções é apenas uma alternativa.

Qual a diferença entre TPH e TPT?

No TPH, toda a hierarquia fica em uma única tabela com uma coluna discriminadora. Já no TPT, cada tipo ganha sua própria tabela, ligada à tabela base pela chave primária.

Quando usar AsSplitQuery?

Use quando a consulta inclui várias coleções e o SQL único gera muitas linhas duplicadas. Lembre que os dados podem mudar entre os comandos.

O EF Core 5 ainda tem suporte?

Não. O suporte terminou em 10 de maio de 2022, então projetos novos devem usar uma versão suportada.