Planejar o Entity Framework Core 5.0

Importante

O EF Core 5.0 já foi lançado. Esta página permanece como um registro histórico do plano.

Conforme descrito no processo de planejamento, reunimos a entrada dos stakeholders em um plano provisório para a versão do EF Core 5.0.

Importante

Esse plano ainda é um trabalho em andamento. Nada aqui é um compromisso. Este plano é um ponto de partida que evoluirá à medida que aprendermos mais. Algumas coisas não planejadas atualmente para 5.0 podem ser retiradas. Algumas coisas atualmente planejadas para 5.0 podem ser pontuadas.

Informações gerais

Número de versão e data de lançamento

Atualmente, o EF Core 5.0 está programado para ser lançado ao mesmo tempo que o .NET 5.0. A versão "5.0" foi escolhida para se alinhar ao .NET 5.0.

Plataformas com Suporte

O EF Core 5.0 está planejado para ser executado em qualquer plataforma .NET Standard 2.1, incluindo o .NET 5.0. Isso faz parte da convergência mais geral de plataformas do .NET para o .NET Core.

O EF Core 5.0 não será executado no .NET Framework.

Alterações de quebra

O EF Core 5.0 conterá algumas alterações significativas, mas elas serão muito menos graves do que o caso do EF Core 3.0. Nossa meta é permitir que a grande maioria dos aplicativos seja atualizada sem interrupções.

Espera-se que haja algumas alterações significativas para provedores de banco de dados, especialmente em relação ao suporte ao TPT. No entanto, esperamos que o trabalho para atualizar um provedor para 5.0 seja menor do que o necessário para atualizar para 3.0.

Temas

Extraímos algumas áreas ou temas importantes que formarão a base para os grandes investimentos no EF Core 5.0.

Mapeamento de muitos para muitos totalmente transparente por convenção

Desenvolvedores potenciais: @smitpatel, @AndriySvyryd e @lajones

Acompanhado pelo nº 10508

Tamanho da camiseta: L

Status: Concluído

Muitos para muitos é o recurso mais solicitado (aproximadamente 506 votos) na lista de pendências do GitHub.

O suporte para relações muitos para muitos pode ser dividido em três áreas principais:

• Ignore as propriedades de navegação, cobertas pelo próximo tema.
• Tipos de entidade de recipiente de propriedades. Elas permitem que um tipo CLR padrão (por exemplo Dictionary) seja usado para instâncias de entidade, de modo que um tipo CLR explícito não seja necessário para cada tipo de entidade. Acompanhado pelo nº 9914.
• Açúcar para facilitar a configuração de relações muitos para muitos.

Além do suporte de navegação de ignorar, agora estamos puxando essas outras áreas de muitos para muitos para o EF Core 5.0 para fornecer uma experiência completa.

Propriedades de navegação muitos para muitos (também conhecido como "ignorar navegação")

Desenvolvedores potenciais: @smitpatel e @AndriySvyryd

Rastreado por nº 19003

Tamanho da camiseta: L

Status: Concluído

Conforme descrito no primeiro tema, o suporte muitos para muitos tem vários aspectos. Este tema controla especificamente o uso de navegação de ignorar. Acreditamos que o bloqueador mais significativo para aqueles que desejam apoio muitos para muitos não é ser capaz de usar as relações "naturais", sem se referir à tabela de junção, na lógica de negócios, como consultas. O tipo de entidade de tabela de junção ainda pode existir, mas não deve atrapalhar a lógica de negócios.

Mapeamento de herança TPT (tabela por tipo)

Desenvolvedor líder: @AndriySvyryd e @smitpatel

Rastreado por nº 2266

Tamanho da camiseta: XL

Status: Concluído

Estamos fazendo TPT porque é um recurso altamente solicitado (~289 votos; 3º no geral) e porque requer algumas alterações de baixo nível que achamos apropriadas para a natureza fundamental do plano geral do .NET 5. Esperamos que isso resulte em alterações significativas para provedores de banco de dados, embora elas sejam muito menos graves do que as alterações necessárias para 3.0.

Inclusão filtrada

Desenvolvedor líder: @maumar

Rastreado por nº 1833

Tamanho da camiseta: M

Status: Concluído

Filtered Include é um recurso altamente solicitado (~376 votos; 2º no geral) que não é uma grande quantidade de trabalho, e que acreditamos que desbloqueará ou facilitará muitos cenários que atualmente exigem filtros no nível do modelo ou consultas mais complexas.

Inclusão de divisão

Desenvolvedor líder: @smitpatel

Acompanhado por nº 20892

Tamanho da camiseta: L

Status: Concluído

O EF Core 3.0 alterou o comportamento padrão para criar uma única consulta SQL para uma determinada consulta LINQ. Isso causou grandes regressões de desempenho para consultas que usam Include para várias coleções.

No EF Core 5.0, estamos mantendo o novo comportamento padrão. No entanto, o EF Core 5,0 agora permitirá a geração de várias consultas para coleta, incluindo onde ter uma única consulta está causando um desempenho insatisfatório.

Dependentes um-para-um necessários

Desenvolvedores potenciais: @AndriySvyryd e @smitpatel

Rastreado por nº 12100

Tamanho da camiseta: M

Status: Concluído

No EF Core 3.0, todos os dependentes, incluindo tipos de propriedade, são opcionais (por exemplo, Person.Address pode ser nulo). No EF Core 5.0, os dependentes podem ser configurados conforme necessário.

Racionalizar ToTable, ToQuery, ToView, FromSql etc.

Desenvolvedores potenciais: @AndriySvyryd e @smitpatel

Rastreado por nº 17270

Tamanho da camiseta: L

Status: Concluído

Fizemos progressos em versões anteriores para dar suporte a SQL bruto, tipos sem chave e áreas relacionadas. No entanto, há lacunas e inconsistências na forma como tudo funciona em conjunto como um todo. A meta da 5.0 é corrigi-las e criar uma boa experiência para definir, migrar e usar diferentes tipos de entidades e suas consultas e artefatos de banco de dados associados. Isso também pode envolver atualizações na API de consulta compilada.

Observe que esse item pode resultar em algumas alterações de falha no nível do aplicativo, pois algumas das funcionalidades que temos atualmente são muito permissivas, de modo que ele pode levar rapidamente as pessoas a poços de falha. Provavelmente, acabaremos bloqueando algumas dessas funcionalidades com diretrizes sobre o que fazer em vez disso.

Aprimoramentos gerais de consulta

Desenvolvedores potenciais: @smitpatel e @maumar

Rastreado por problemas marcados com area-query no marco 5.0

Tamanho da camiseta: XL

Status: Concluído

O código de conversão de consulta foi reescrito extensivamente para EF Core 3,0. O código de consulta geralmente está em um estado muito mais robusto por causa disso. Para 5,0, não estamos planejando fazer alterações de consulta principais, fora das necessárias para dar suporte a TPT e ignorar Propriedades de navegação. No entanto, ainda há um trabalho significativo necessário para corrigir alguma dívida técnica à esquerda da revisão 3.0. Também planejamos corrigir muitos bugs e implementar pequenos aprimoramentos para melhorar ainda mais a experiência de consulta geral.

Migração e experiência de implantação

Desenvolvedores potenciais: @bricelam

Rastreado por nº 19587

Tamanho da camiseta: L

Status: Escopo/concluído

Escopo: o recurso de pacotes de migrações foi adiado até depois da versão do EF Core 5.0. No entanto, várias outras melhorias direcionadas relacionadas às migrações serão incluídas no EF Core 5.0

Atualmente, muitos desenvolvedores migram seus bancos de dados no momento da inicialização do aplicativo. Isso é fácil, mas não é recomendado porque:

• Vários threads/processos/servidores podem tentar migrar o banco de dados simultaneamente
• Os aplicativos podem tentar acessar o estado inconsistente enquanto isso está acontecendo
• Normalmente, as permissões de banco de dados para modificar o esquema não devem ser concedidas para execução do aplicativo
• É difícil reverter para um estado limpo se algo der errado

Queremos oferecer uma experiência melhor aqui que permita uma maneira fácil de migrar o banco de dados no momento da implantação. Isso deve:

• Trabalhar no Linux, Mac e Windows
• Seja uma boa experiência na linha de comando
• Cenários de suporte com contêineres
• Trabalhar com fluxos/ferramentas de implantação do mundo real comumente usados
• Integrar em pelo menos o Visual Studio

O resultado provavelmente será muitas pequenas melhorias no EF Core (por exemplo, melhores migrações no SQLite), juntamente com diretrizes e colaborações de longo prazo com outras equipes para melhorar experiências de ponta a ponta que vão além apenas do EF.

Experiência de plataformas do EF Core

Desenvolvedores potenciais: @roji e @bricelam

Rastreado por nº 19588

Tamanho da camiseta: L

Status: Escopo/concluído

Escopo: as diretrizes e exemplos de plataforma são publicados para Blazor, Xamarin, WinForms e WPF. O Xamarin e outros trabalhos de AOT/vinculador agora estão planejados para o EF Core 6.0.

Temos boas diretrizes para usar o EF Core em aplicativos Web tradicionais semelhantes a MVC. As diretrizes para outras plataformas e modelos de aplicativo estão ausentes ou desatualizadas. Para o EF Core 5.0, planejamos investigar, melhorar e documentar a experiência de usar o EF Core com:

• Blazor
• Xamarin, incluindo o uso da história do AOT/vinculador
• WinForms/WPF/WinUI e possivelmente outras estruturas de interface do usuário

Isso provavelmente será muitas pequenas melhorias no EF Core, juntamente com diretrizes e colaborações de longo prazo com outras equipes para melhorar experiências de ponta a ponta que vão além apenas do EF.

As áreas específicas que planejamos examinar são:

• Implantação, incluindo a experiência de uso de ferramentas EF, como para Migrações
• Modelos de aplicativo, incluindo Xamarin e Blazor, e provavelmente outros
• Experiências do SQLite, incluindo a experiência espacial e recompilações de tabela
• Experiências de vinculação e AOT
• Integração de diagnóstico, incluindo contadores perf

Desempenho

Desenvolvedor líder: @roji

Acompanhado por problemas rotulados com area-perf no marco 5.0

Tamanho da camiseta: L

Status: Escopo/concluído

Escopo: as principais melhorias de desempenho no provedor Npgsql estão concluídas. Outros trabalhos de desempenho agora estão planejados para o EF Core 6.0.

Para o EF Core, planejamos melhorar nosso conjunto de parâmetros de comparação de desempenho e fazer melhorias de desempenho direcionadas para o runtime. Além disso, planejamos concluir o novo ADO.NET API de envio em lote que foi protótipo durante o ciclo de lançamento 3.0. Também na camada ADO.NET, planejamos melhorias de desempenho adicionais para o provedor Npgsql.

Como parte desse trabalho, também planejamos adicionar contadores de desempenho do ADO.NET/EF Core e outros diagnósticos, conforme apropriado.

Documentação de arquitetura/colaborador

Principal documentador: @ajcvickers

Rastreado por nº 1920

Tamanho da camiseta: L

Status: Recortar

A ideia aqui é facilitar a compreensão do que está acontecendo nos internos do EF Core. Isso pode ser útil para qualquer pessoa que use o EF Core, mas a principal motivação é tornar mais fácil para pessoas externas:

• Contribuir para o código do EF Core
• Criar provedores de banco de dados
• Criar outras extensões

Atualização: Infelizmente, esse plano era muito ambicioso. Ainda acreditamos que isso é importante, mas infelizmente não chegará com o EF Core 5.0.

Documentação do Microsoft.Data.Sqlite

Principal documentador: @bricelam

Rastreado por nº 1675

Tamanho da camiseta: M

Status: Concluído. A nova documentação está ativa no Microsoft Learn.

A equipe de EF também é dona do provedor de ADO.NET Microsoft.Data.Sqlite. Planejamos documentar totalmente esse provedor como parte da versão 5.0.

Documentação geral

Principal documentador: @ajcvickers

Acompanhado por problemas no repositório de documentação no marco 5.0

Tamanho da camiseta: L

Status: em andamento

Já estamos no processo de atualização da documentação para as versões 3.0 e 3.1. Também estamos trabalhando em:

• Uma revisão dos artigos de introdução para torná-los mais acessíveis/fáceis de seguir
• Reorganização de artigos para facilitar a localização e a adição de referências cruzadas
• Adicionando mais detalhes e esclarecimentos a artigos existentes
• Atualizando os exemplos e adicionando mais exemplos

Corrigindo bugs

Acompanhado por problemas rotulados com type-bug no marco 5.0

Desenvolvedores: @roji, @maumar, @bricelam, @smitpatel, @AndriySvyryd, @ajcvickers

Tamanho da camiseta: L

Status: em andamento

No momento em que escrevo, temos 135 bugs triados para serem corrigidos na versão 5.0 (com 62 já corrigidos), mas há uma sobreposição significativa com a seção Aprimoramentos gerais de consulta acima.

A taxa de entrada (problemas que acabam como trabalho em um marco) foi de cerca de 23 problemas por mês ao longo da versão 3.0. Nem todos eles precisarão ser corrigidos em 5.0. Como uma estimativa aproximada, planejamos corrigir mais 150 problemas no período de 5.0.

Pequenos aprimoramentos

Acompanhado por problemas rotulados com type-enhancement no marco 5.0

Desenvolvedores: @roji, @maumar, @bricelam, @smitpatel, @AndriySvyryd, @ajcvickers

Tamanho da camiseta: L

Status: Concluído

Além dos recursos maiores descritos acima, também temos muitas melhorias menores agendadas para 5.0 para corrigir "cortes de papel". Observe que muitos desses aprimoramentos também são abordados pelos temas mais gerais descritos acima.

Abaixo da linha

Acompanhado por problemas rotulados com consider-for-next-release

Essas são correções de bug e aprimoramentos que não estão agendados no momento para a versão 5.0, mas veremos como metas de alongamento, dependendo do progresso feito no trabalho acima.

Além disso, sempre consideramos as questões mais votadas ao planejar. Cortar qualquer um desses problemas de uma versão é sempre doloroso, mas precisamos de um plano realista para os recursos que temos.

Sugestões

Seus comentários sobre o planejamento são importantes. A melhor maneira de indicar a importância de um problema é votar (polegar para cima) nesse problema no GitHub. Esses dados serão alimentados no processo de planejamento para a próxima versão.