Embora separado do ciclo de lançamento do .NET Core, o EF Core está desenvolvendo seu roadmap 3.0. Junto com isso, há algumas alterações importantes no Entity Framework original.
Entity Framework 6.3 no .NET Core 3
Primeiro de tudo, o Entity Framework está concluído. Em termos de recursos e funcionalidade, nada de novo está planejado para o Entity Framework 6.x e é altamente improvável que haja um Entity Framework 7.
Dito isso, o Entity Framework não foi completamente esquecido. A Microsoft reconheceu que a portabilidade do código de banco de dados legado do EF 6 para o EF Core não é necessariamente fácil, o que o torna um obstáculo para a adoção do .NET Core.
O plano atual é oferecer uma versão parcial do Entity Framework que é executado no .NET Core. Isso exigirá novos provedores específicos de banco de dados. Além disso, alguns recursos como dados espaciais no SQL Server, não serão suportados.
Os itens restantes neste artigo se aplicam ao EF Core.
Mais Queries Server-Side
Muitas vezes pode ser difícil, até mesmo impossível, traduzir uma consulta LINQ em uma consulta SQL correspondente. Muitos ORMs lidam com esse problema simplesmente lançando uma runtime exception quando a tradução falha, mas o EF Core tenta ser mais tolerante. Quando não é possível compreender totalmente uma consulta LINQ, ela é traduzida parcialmente em SQL e, em seguida, executa as operações restantes do lado do cliente. Embora isso possa resultar em um desempenho muito ruim, muitos desenvolvedores preferem essa opção do que a consulta simplesmente falhar completamente.
Diego B Vega escreveu:
No EF Core 3.0, estamos planejando fazer mudanças profundas em como nossa implementação LINQ funciona e como a testamos. Os objetivos são torná-lo mais robusto (por exemplo, para evitar a quebra de consultas em versões de correções de bugs), de forma que seja possível traduzir mais expressões corretamente em SQL, gerar consultas mais eficientes e evitar que consultas ineficientes passem despercebidas.
Suporte a NoSQL
Há muito tempo existe o desejo de um ORM que lide perfeitamente com bancos de dados SQL e NoSQL. Originalmente anunciado como parte do roadmap do EF Core 2.1, a Microsoft ainda está tentando introduzir esse recurso. O novo plano é começar a oferecer suporte ao Cosmo DB no EF Core 3.0.
Suporte a C# 8.0
O EF Core 3.0 será a primeira versão a incluir o suporte ao C# 8. Isso significa principalmente que a API será atualizada para incluir tipos de referência nuláveis e fluxos assíncronos. Como isso será feito ainda está sendo determinado, já que uma das metas do EF Core 3.0 é permanecer uma biblioteca do .NET Standard 2.0. Isso poderia impedi-lo de usar alguns recursos do C# 8.
Como o .NET Framework não oferecerá suporte a todos os novos recursos do C# 8, é improvável que o Entity Framework 6.3 também seja atualizado para incluir o suporte ao C# 8.
Melhor suporte para Views
Ao contrário do Entity Framework, o EF Core não pode gerar queries tipadas para views no banco de dados. As queries tipadas são usadas para entidades que podem ser lidas, mas não gravadas no banco de dados. Normalmente, isso seria o resultado da consulta de uma view, stored procedure, ou função com valor de tabela.
Espera-se que esta supervisão no gerador de código seja corrigida no EF Core 3.0.
Relacionamentos muitos-para-muitos
Para representar um relacionamento muitos-para-muitos no EF Core, atualmente é preciso um "join entity" que represente o mapeamento da tabela. Com o recurso "property bag entities", o EF Core está mais perto de eliminar esse requisito.
Esse recurso se resume em habilitar entidades que armazenem dados em propriedades indexadas em vez de propriedades regulares, e também sobre poder usar instâncias da mesma classe .NET (potencialmente algo tão simples quanto um Dictionary <string, object>) para representar diferentes tipos de entidades no mesmo modelo EF Core.
Observe que o Entity Framework já oferece suporte ao relacionamento muitos-para-muitos sem um join entity.
Recursos que não estão no roadmap do EF Core 3.0
Com um orçamento limitado, nem tudo que foi solicitado entrará no roadmap. Aqui estão alguns dos principais candidatos que não entraram no orçamento.
Stored Procedures
O suporte de primeira classe para stored procedures não será oferecido do EF Core 3.0. A solução alternativa usando tipos de consulta e SQL bruto ainda se aplica nesse meio tempo.
Tabela por tipo de herança
Quando as tabelas são muito largas com muitas colunas, uma técnica para resolver o problema é a tabela por tipo de herança. Com esse modelo, cada linha é identificada como pertencente a um dos vários subtipos. Cada subtipo obtém sua própria tabela apenas com as colunas exclusivas desse subtipo. Somente colunas comuns a todos os subtipos permanecem na tabela original.
Atualmente, a tabela por tipo de herança é suportada pelo Entity Framework, mas não pelo EF Core. Embora tenha sido uma característica comumente solicitada desde pelo menos 2015, ela também faz parte desta versão. Para alguns, é visto como um antipadrão porque, quando usado de maneira inadequada, pode prejudicar o desempenho.
Outros contestam que tabela por tipo de herança pode melhorar drasticamente o desempenho, já que o custo de unir a tabela de base e subtipo pode ser menor do que lidar com uma única tabela que é muito ampla. Além disso, bancos de dados do mundo real já usam esse padrão e o EF Core precisa ser capaz de trabalhar com esses bancos de dados existentes.
Um novo argumento é que a herança de TPT (Table Per Type Inheritance) não é necessária no EF Core porque já existe no Entity Framework e o EF será portado para o .NET Core. O refutável a esta afirmação é que as pessoas podem precisar tanto de herança TPT quanto de um recurso EF-Core somente.
Visual Studio Designer
Diego B Vega escreveu:
Entendemos que um designer pode ser um recurso importante para alguns de nossos clientes adotarem o EF Core, mas não vemos muito feedback indicando que isso é mais importante do que os outros recursos em nosso backlog. Seria interessante saber se você tentou desenvolver primeiro o código e se está ciente de que o ferramental pode fazer engenharia reversa de um banco de dados existente em um modelo EF Core.
Upsert
O Upsert é a capacidade de inserir ou atualizar um registro condicionalmente, é considerado um recurso ORM de segunda linha. Embora não seja necessário, é bom ter como reduzir as ida e vindas acessando o banco de dados e simplificar o código. No entanto, atualmente não se encaixa no modelo EF Core. Em parte, porque a maneira como precisa ser implementado varia muito entre os bancos de dados. Alguns têm sintaxe explícita, mas única. Outros aproveitam a instrução MERGE, que pode ser problemática, pois não é necessariamente atômica. Há também o Jet/MS-Access, que não suportam o upsert, mas pode ser simulado usando várias queries.
Upsert está sendo discutido atualmente como parte do encadeamento de suporte Merge/Upsert/AddOrUpdate no Github.
GraphQL
Implementar o GraphQL é muito difícil. A linguagem de consulta é surpreendentemente complexa e até mesmo uma implementação parcial não é realmente viável sem uma estrutura ou biblioteca que a suporte.
A Microsoft tinha um protótipo para o GraphQL usando o EF Core há alguns anos que nunca foi lançado publicamente. E eles estão entretendo a idéia de revisitá-lo no futuro, embora existam muitas questões de design do GraphQL a serem respondidas.