Entity Framework Core 5 – Armadilhas a evitar e ideias a experimentar | O blog das ferramentas .NET (2023)

Ferramentas .NETComo fazer

Nesta postagem, veremos algumas armadilhas e ideias que usuários do EF Core como você podem querer considerar ao desenvolver um aplicativo.

Entity Framework Core (EF Core)é uma reescrita completa da estrutura de mapeamento de banco de dados de objetos da Microsoft. Começar a usar o EF Core é relativamente simples, mas dominá-lo pode levar uma carreira inteira.

Como usuário de longa data de versões anteriores do Entity Framework, comecei a escrever este post com muitas noções preconcebidas sobre as armadilhas dessa experiência. Embora algumas armadilhas conceituais tenham ocorrido em versões anteriores do EF, o cuidado da equipe do EF Core em lidar com problemas anteriores ficou evidente para mim quando li a documentação do EF Core e trabalhei nos exemplos de código desta postagem.

Sabendo que o EF Core é diferente, dediquei algum tempo para explorar a documentação do EF Core e determinar as armadilhas existentes que você pode encontrar ao iniciar sua jornada no EF Core. Compilei e consolidei essas informações para ajudá-lo a obter uma visão geral dos possíveis erros que você pode encontrar.

Embora este post esteja repleto de informações importantes, não é conclusivo.

Ferramentas globais x ferramentas locais

O EF Core passou por várias iterações para fornecer uma interface de linha de comando repetível. A atualização de versões anteriores pode nos levar a instalar as ferramentas EF Core CLI globalmente em nossos ambientes de desenvolvimento. Embora possamos instalar as ferramentas globalmente, é melhor criar versões das ferramentas da CLI e do EF Core juntas em sua solução.

Para instalar a ferramenta localmente para cada solução, primeiro precisamos criar um manifesto da ferramenta. Na pasta da solução, podemos executar o seguinteponto Netcomando.

novo manifesto de ferramenta dotnet

Este comando criará um novo.configdiretório com umdotnet-tools.jsonarquivo. Podemos então instalar as ferramentas CLI em nossa solução localmente. A partir daqui, podemos instalar as ferramentas EF Core CLI.

ferramenta dotnet instalar dotnet-ef

A documentação do EF Corerecomenda que os desenvolvedores usem o pacote de ferramentas que corresponda à versão principal dos pacotes de tempo de execução. As últimas versões são5.0.1para os pacotes CLI e EF Core, a partir da publicação do artigo. Instalar as ferramentas na solução nos ajuda a evitar desvios e conflitos ao trabalhar em várias soluções com versões variadas.

Adotando nomes não convencionais

Os pacotes de tempo de execução do EF Core 5 contêmconvenções em torno da nomenclatura do esquema, que normalmente são consideradas práticas recomendadas. O EF Core permite que os desenvolvedores trabalhem com unidades organizacionais para se adaptar a diferentes estilos de nomenclatura. Ainda assim, as modificações nas convenções de nomenclatura no EF Core vêm com custos de manutenção significativos e o potencial para introduzir bugs de mapeamento. Os desenvolvedores devem adotar os padrões do EF Core o máximo possível para evitar exceções e casos extremos estranhos.

Dependendo da sua organização e delegação de responsabilidade, pode ser melhor conversar sobre as convenções de nomenclatura do EF Core e adotá-las como uma metodologia compreendida para projetar e desenvolver o esquema. Os administradores e desenvolvedores de banco de dados devem trabalhar para agregar valor aos usuários. Se éimpossívelpara fazer isso por motivos organizacionais, considere a próxima seção como uma possível solução.

Esquecendo a engenharia reversa

Ao trabalhar com um banco de dados legado ou dinâmica de poder organizacional complicada, podemos ser tentados a criar cada entidade e definir cada relacionamento dentro doDbContext.OnModelCriandométodo. Os desenvolvedores devem primeiro olhar paraoandaimesrecursos incorporados às ferramentas EF Core CLI.

Podemos pedir à CLI para estruturar entidades e relacionamentos de um banco de dados existente usando oandaimecomando.

dotnet ef dbcontext scaffold "Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=Chinook" Microsoft.EntityFrameworkCore.SqlServer

Devemos especificar o provedor de banco de dados apropriado durante o scaffolding para que o scaffolding possa respeitar a sintaxe SQL do nosso banco de dados.

Também podemos selecionar seletivamente partes de um banco de dados existente, especificando nomes de tabelas.

dotnet ef dbcontext scaffold ... --table Artista --table Álbum

As tabelas de direcionamento são úteis ao criar microsserviços ou aplicativos .NET projetados para executar uma tarefa de nicho.

Existem desvantagens no scaffolding que podemos evitar começando com uma abordagem Code-First. Podemos definir relacionamentos lógicos em C# que não podemos representar apenas por meio do esquema; esses conceitos incluem hierarquias de herança, tipos de propriedade e divisão de tabelas. Além disso, os mecanismos de simultaneidade não sofrem engenharia reversa peloandaimecomando. Por fim, os tipos de referência anuláveis ​​também não sofrem engenharia reversa e devemos adicioná-los após o fato.

As maiores preocupações da engenharia reversa de um banco de dados existente vêm de mudanças de conceito que ocorrem a partir de uma base de código e esquema de banco de dados divergentes. Se o banco de dados for relativamente estável, isso pode não ser um problema. Ainda assim, um banco de dados em progresso ativo pode causar dores de cabeça aos desenvolvedores enquanto eles tentam acompanhar as mudanças de esquema.

Nem todos os bancos de dados são iguais

O EF Core fornece uma interface comum para vários mecanismos de banco de dados relacional. Esses provedores incluem SQLite, Microsoft SQL Server, PostgreSQL e Oracle. As semelhanças entre cada provedor podem nos levar a uma falsa sensação de segurança sobre a intercambialidade desses motores, mas é essencial reconhecer suas diferenças.

A abstração de consulta do EF Core é vazada, com muitos dos conceitos de banco de dados encontrando seu caminho para a interface. Os vazamentos conceituais não sãoruim, mas eles devem ser levados em consideração quando começamos a usar recursos comoDbFunctioneFromSqlpara executar recursos específicos do mecanismo de banco de dados.

Ao testar, oA documentação do EF Core recomenda três opções:

• Executar testes no mesmo mecanismo de banco de dados usado na produção.
• Executar testes em algum outro mecanismo de banco de dados que é"mais fácil"gerenciar.
• Usando dublês de teste para evitar o uso de um banco de dados.

A melhor opção é executar nossos testes em um ambiente de produção, pois eliminaremos os problemas que podem surgir das variações do mecanismo. Pode ser difícil dependendo do banco de dados, mas com tecnologias de conteinerização comoDocker, o problema de gerenciar instâncias isoladas nunca foi tão fácil para os desenvolvedores.

Algumas pessoas podem querer testar em um mecanismo diferente, por exemplo, o SQL Server pode ser o mecanismo de banco de dados de destino, mas os testes são executados em uma instância do SQLite. Embora possível, essa abordagem leva a mais problemas, como diferenças de sintaxe SQL e a necessidade de gerenciar uma estratégia de migração totalmente diferente.

Finalmente, stubs ou mocks podem parecer uma"bom"ideia, mas os mecanismos de banco de dados são preenchidos com um grau de nuance e complexidade que é difícil de entender completamente sem um investimento de tempo significativo. A incompatibilidade entre o comportamento assumido do mecanismo e o comportamento real pode nos levar a introduzir bugs.

Consultas que não incluem dados relacionados

O EF Core abandonou o carregamento lento como um recurso padrão. As propriedades de navegação ainda existem como parte da abordagem de design Code-First, mas muitas dessas propriedades de navegação exigem explicitamente que o EF Core carregue os dados.

Dado o seguinteEntretenimentoDbContext, nós temos umaFilmemodelo.

public abstract class Production{ public int Id { get; definir; } string pública Nome { get; definir; } Public DateTime Release { get; definir; } public List Caracteres { get; definir; } = new List(); public List Classificações { get; definir; } = new List();}public class Movie : Production{ public int DurationInMinutes { get; definir; } public double WorldwideBoxOfficeGross { get; definir; }}

EF Core não carregará oPersonagenseavaliaçõespropriedades de navegação na consulta a seguir.

var filmes = banco de dados.Movies .OrderByDescending(x => x.WorldwideBoxOfficeGross);

Só depois de usar oIncluirveremos as coleções preenchidas.

var filmes = banco de dados .Movies .Include(m => m.Characters) .Include(m => m.Ratings) .OrderByDescending(x => x.WorldwideBoxOfficeGross);

Esquecer de incluir dados importantes pode levar ao pânico quando os usuários pensam que o sistema não está salvando dados ou excluiu dados existentes.

Acompanhamento de consultas somente leitura

EF Core implementa oUnidade de trabalhopadrão, acompanhando as alterações em nossas entidades e, por fim, enviando essas alterações de volta ao nosso mecanismo de banco de dados. A abordagem tem muitas vantagens ao modificar dados, mas vem com um custo de desempenho perceptível.

Instanciando umDbContextA instância é uma operação relativamente barata, em que a maior parte do custo de uso do EF Core vem da análise de expressão, operações de rede e rastreamento de objetos. Podemos desativar o rastreamento de objetos usando oAsNoTrackingmétodo em nossas consultas LINQ.

var filmes = banco de dados .Movies .AsNoTracking() .OrderByDescending(x => x.WorldwideBoxOfficeGross);

Desativar o rastreamento de objetos pode acelerar cenários de leitura, como pontos de extremidade somente leitura em uma API HTTP. Existe um risco potencial de usar oAsNoTrackingrecurso. Embora reduza o custo de processamento de entidades para rastreamento de objetos, pode aumentar a sobrecarga de memória. Vejamos um exemplo.

var filmes = banco de dados .Movies .AsNoTracking() .Include(m => m.Characters) .ThenInclude(c => c.Actor) .AsNoTracking() .OrderByDescending(x => x.WorldwideBoxOfficeGross);

No caso desta consulta, umAtorpode estar em vários filmes. Como o EF Core não está mais rastreando entidades, o EF Core alocará uma entidade para o mesmoAtorvárias vezes.

Podemos optar pela resolução de identidade enquanto desativamos o rastreamento de objetos usando o recém-adicionadoAsNoTrackingWithIdentityResolutionmétodo.

var filmes = banco de dados .Movies .AsNoTrackingWithIdentityResolution() .Include(m => m.Characters) .ThenInclude(c => c.Actor) .AsNoTracking() .OrderByDescending(x => x.WorldwideBoxOfficeGross);

Todas as instâncias do mesmoAtormodel apontará para o mesmo objeto, evitando assim a superalocação.

Não habilite o carregamento lento

Carregamento lentoé um recurso que tem causado inúmeros problemas de produção, e a equipe do EF Corelegitimamentetornou inconveniente habilitar esse recurso.

É altamente recomendávelnão habilitaresse recurso, pois as propriedades de navegação tornam-se mecanismos opacos que acionam idas e vindas desnecessárias e caras ao banco de dados.

Para habilitar o carregamento lento, as pessoas precisam instalar oMicrosoft.EntityFrameworkCore.Proxiespacote.

dotnet adicionar pacote Microsoft.EntityFrameworkCore.Proxies

Em seguida, a partir doAo configurarmétodo de umDbContext, podemos chamar oUseLazyLoadingProxiesmétodo.

substituição protegida void OnConfiguring(DbContextOptionsBuilder optionsBuilder) => optionsBuilder .UseLazyLoadingProxies() .UseSqlServer(myConnectionString);

Vejamos um exemplo N+1 com nossoFilmemodelo.

var filmes = banco de dados .Movies .OrderByDescending(x => x.WorldwideBoxOfficeGross);foreach (var filme em filmes){ // uma chamada de banco de dados por Character foreach (var character in movie.Characters) { // chamada de banco de dados para Actor Console. WriteLine(personagem.Ator.Nome); }}

Embora possa parecer que executamos uma única consulta, conforme percorremos nossoFilmeentidade, estamos fazendo uma consulta adicional para cada propriedade de navegação. Para cadaFilme(N), estamos fazendo uma chamada separada para o banco de dados para cadaPersonagementidade (+1). E neste exemplo, outra chamada separada paraAtor. Isso é altamente ineficiente!Os amigos não permitem que os amigos ativem o carregamento lento.

Esquecer as projeções

Por mais que a abstração do EF Core pareça C#, é melhor tratá-la mais como a interface do banco de dados. Os modelos definidos em nossoDbContextrepresentam nosso esquema e devem ser usados ​​para escrever consultas mais eficientes. Usar as entidades é equivalente a realizar umSelecione * Da Tabelaconsulta. Não é erradoselecione *, mas ao empregarSelecionemétodo, podemos usarprojeções, o que nos permite:

• Reduza a quantidade de dados transmitidos pela rede.
• Melhore os tempos de execução do SQL.
• Retorne explicitamente apenas os dados de que precisamos.

Vejamos como projetar nossoFilmemodelo em um resultado que inclui dados de personagens e atores.

var filmes = banco de dados .Movies .AsNoTracking() .OrderByDescending(x => x.WorldwideBoxOfficeGross) .Select(m => new { m.Name, Characters = m.Characters.Select(c => new { c.Name, Actor = c.Actor.Name }) });

Em vez de usar resultados de objetos anônimos, também podemos projetar diretamente em objetos de transferência de dados destinados a serem consumidos pelos chamadores. Neste exemplo, selecionamos diretamente em nossos modelos de resposta da API HTTP para máxima eficiência.

var filmes = banco de dados .Movies .AsNoTracking() .OrderByDescending(x => x.WorldwideBoxOfficeGross) .Select(m => new MovieResponse { Id = m.Id, Name = m.Name, Characters = m.Characters.Select(c => new CharacterResponse { Name = c.Name, Actor = c.Actor.Name }) });

Esquecer de adicionar índices

É fácil esquecer a escala dos dados com os quais lidaremos na produção durante o desenvolvimento. Além disso, à medida que nosso aplicativo cresce e adicionamos recursos, nossas necessidades de consulta mudam. A maioria dos mecanismos de banco de dados adicionará índices a chaves primárias e estrangeiras, mas também podemos ter colunas que fornecem outras oportunidades de particionamento.

Com Núcleo EF,podemos aplicar um índiceusando oModelBuilderinstância dentro doOnModelCreatingmétodo. No momento em que escrevo este post, os índicessó pode ser aplicado com oModelBuilder, e não há atributo de anotação de dados equivalente.

modelBuilder.Entity() .HasIndex(b => b.Release);

O EF Core tem muitas opções para especificar um índice, desde exclusividade, nomenclatura, filtragem, várias colunas e filtros aplicados.

Os índices são uma parte essencial da otimização do acesso ao banco de dados. É vital medir o desempenho da consulta e aplicar índices quando necessário.

Executando operações de migração

O EF Core oferece suporte a um modelo de migração muito aprimoradoem comparação com seu antecessor, o EF 6. O EF Core mais recente apresenta arquivos de migração amigáveis ​​ao controle de versão, ferramentas CLI e fluxos de trabalho repetíveis.

Podemos querer permitir que nossos aplicativos executem migrações na inicialização do aplicativo, mas é melhor não fazer isso por vários motivos:

• Operações caras podem exceder o limite de tempo limite do SQL padrão do .NET, lançar exceções e deixar os aplicativos em um estado de inicialização interrompido.
• Várias instâncias de seu aplicativo podem tentar competir para aplicar migrações, causando debates e contenção desnecessária.
• As migrações são executadas sem mecanismos de verificação de qualidade e sem oportunidade de revisão.

Núcleo EFpode gerar scriptsque podemos aplicar a um banco de dados de produção. OA documentação da Microsoft sugereScripts SQL como a abordagem recomendada para implantar alterações de esquema em ambientes de produção:

• As equipes podem revisar os scripts SQL quanto à precisão e testar possíveis perdas de dados.
• Os scripts SQL podem ser usados ​​em conjunto com uma tecnologia de implantação e integrados a um processo de integração contínua.
• Os scripts SQL podem ser fornecidos a uma unidade de administração de banco de dados e aplicados fora dos horários de pico.

Podemos usar as mesmas ferramentas EF CLI para gerar scripts SQL. A abordagem mais poderosa é usandoDeeParaargumentos.

script de migrações dotnet ef [de] [para]

Podemos deixar de fora oParaargumento, pois podemos sugerir que queremos gerar até a migração mais recente.

Devemos sempre abordar a migração de dados de produção com extremo cuidado, pois qualquer modificação pode levar à perda de dados. Automatizar a aplicação de alterações de esquema é ideal, pois remove o potencial de erro humano.

Usando tabela por tipo

O EF Core tem dois modelos de herança:Tabela por hierarquia (TPH)eTabela por tipo (TPT).

A abordagem TPH usa uma única tabela com colunas para cada propriedade exclusiva de uma entidade com umDiscriminadorcoluna. No exemplo a seguir, ambosFilmeeSeriescompartilhar umProduçõesmesa.

public abstract class Production{ public int Id { get; definir; } string pública Nome { get; definir; } Public DateTime Release { get; definir; } public List Caracteres { get; definir; } = new List(); public List Classificações { get; definir; } = new List();}public class Movie : Production{ public int DurationInMinutes { get; definir; } public double WorldwideBoxOfficeGross { get; definir; }}public class Series : Production{ public int NumberOfEpisodes { get; definir; }}

Filmeas linhas irão conterNulovalores para oNumberOfEpisodescolunas, enquantoSerieslinhas terão vazioDuraçãoEmMinutoseWorldwideBoxOfficeGrosscolunas.

A abordagem TPT colocaria cada entidade respectiva em uma tabela separada.

As propriedades que pertencem exclusivamente a um tipo base ou tipo derivado são armazenadas em uma tabela que mapeia para esse tipo. As tabelas que mapeiam para tipos derivados também armazenam uma chave estrangeira que une a tabela derivada à tabela base. —Documentação da Microsoft

(Video) The Howling Mines | Critical Role: THE MIGHTY NEIN | Episode 6

Embora possa parecer uma abordagem "mais limpa" para a modelagem de dados, ela tem um custo caro ao fazer consultas em toda a hierarquia.

Vejamos uma consulta direta.

var mais altaRated = database .Productions .Select(x => new { id = x.Id, name = x.Name, avg = x.Ratings.Average(r => r.Stars), type = x.GetType(). Nome }) .OrderByDescending(x => x.avg);

Com o TPH, geraríamos uma instrução SQL equivalente à consulta de uma única tabela.

selecione * de [Produções]

Com o TPT, agora precisaríamos juntar várias tabelas. O custo de unir várias tabelas aumenta à medida que adicionamos novas entidades à nossa hierarquia, até o ponto em que o desempenho de nosso aplicativo é prejudicado e temos alguns usuários infelizes.

Os desenvolvedores só devem considerar o uso de uma abordagem TPT quando não houver chance de precisar executar uma consulta hierárquica que envolva várias entidades. Mesmo nesse cenário, porém, o que a herança de entidade está alcançando?

Duplicação de colunas compartilhadas

Ao usar herança, geralmente definimos propriedades compartilhadas em tipos básicos, mas pode haver uma instância em que esse não seja o caso. Vejamos um exemplo em que dois modelos em nossa hierarquia compartilham o mesmo nome de propriedade sem herdar do tipo base.

classe abstrata pública Veículo {}classe pública Motocicleta : Veículo {}classe pública Carro : Veículo{ public int NumberOfDoors { get; definir; }}public class Plane : Vehicle{ public int NumberOfDoors { get; definir; }}

Se não for explicitamente instruído a usar a mesma coluna, o EF Core criará uma coluna duplicada paraNumberOfDoors. UsandoModelBuilder, podemos usar a mesma coluna.

modelBuilder.Entity() .Property(c => c.NumberOfDoors) .HasColumnName(nameof(Car.NumberOfDoors));modelBuilder.Entity() .Property(c => c.NumberOfDoors) .HasColumnName( nameof(Plane.NumberOfDoors));

O uso da interface do construtor de modelo para combinar colunas deve aumentar a eficiência das consultas SQL.

Excluindo dados

"Excluir" é uma daquelas palavras que podem ter um significado diferente dependendo da nossa perspectiva. Como usuários, queremos exclusões para contabilizar erros e recuperar qualquer informação que removemos acidentalmente. Como desenvolvedores, e no caso do EF Core, excluir é inabalável e sem remorso sobre a remoção permanente de nossos dados. Ao desenvolver um novo aplicativo, podemos tender para a conveniência de exclusões definitivas, mas podemos adicionarexclusões suavesaos nossos aplicativos com um pouco de esforço.

O EF Core vem comFiltros de consulta globaisque fazem a implementaçãoexclusões suavesdireto. Primeiro começamos adicionando uma coluna booleana deEsta deletadoà nossa entidade. Quando esta coluna éverdadeiro, então nossos dados são excluídos de forma reversível.

public abstract class Production{ public int Id { get; definir; } string pública Nome { get; definir; } Public DateTime Release { get; definir; } public bool IsDeleted { get; definir; } public List Caracteres { get; definir; } = new List(); public List Classificações { get; definir; } = new List();}

Na nossaOnModelCreatingmétodo, podemos aplicar um filtro de consulta que se aplica a qualquer consulta realizada noProduçãoentidade.

modelBuilder.Entity() .HasQueryFilter(m => !m.IsDeleted);

Podemos escrever consultas como normalmente faríamos com nosso filtro de consulta aplicado a qualquerProduçãoconsulta.

explosão cartesiana

As junções são parte integrante dos bancos de dados relacionais. Eles nos permitem criar linhas de tabelas relacionadas. Embora seja um recurso poderoso, ele vem com desvantagens. Tome a seguinte relação.

Filme -> Personagens -> Ator

Um filme em que um ator interpreta vários personagens duplicará os dados doFilmeeAtortabelas em nossos resultados. Vamos escrever uma consulta e ver o SQL gerado. Dada a seguinte instrução LINQ:

SELECT "p".."Id", "p".."Discriminador", "p".."Nome", "p".."Release", "p".."DuraçãoEmMinutos", "p".."WorldwideBoxOfficeGross", " t"."Id", "t".."ActorId", "t".."Name", "t".."ProductionId", "t"."Id0", "t"."Name0"FROM "Productions" AS "p"LEFT JOIN ( SELECT "c".."Id", "c".."ActorId", "c".."Nome", "c".."ProductionId", "a"."Id" AS "Id0 ", "a".."Nome" AS "Nome0" FROM "Personagens" AS "c" INNER JOIN "Atores" AS "a" ON "c"."ActorId" = "a"."Id") AS "t " ON "p".."Id" = "t".."ProductionId"WHERE "p".."Discriminador" = 'Filme'ORDER BY "p".."WorldwideBoxOfficeGross" DESC, "p".."Id", "t "."Id", "t".."Id0"

Executando nossa consulta em um banco de dados, veremos estes resultados:

1,Filme,Avengers: Endgame,2019-04-26 00:00:00,181,2797800564.0,1,1,Tony Stark,1,1,Robert Downey Jr.1,Filme,Avengers: Endgame,2019-04-26 00 :00:00,181,2797800564.0,2,2,Steve Rogers,1,2,Chris Evans1,Filme,Avengers: Endgame,2019-04-26 00:00:00,181,2797800564.0,3,3,Okoye,1,3, Danai Guira5,Filme,Downton Abbey,2020-09-20 00:00:00,120,194051302.0,8,8,Violet Crawley,5,8,Maggie Smith5,Filme,Downton Abbey,2020-09-20 00:00:00,120 ,194051302.0,9,9,Lady Mary Crawley,5,9,Michelle Dockery3,Filme,Ip Man 4,2019-12-25 00:00:00,105,192617891.0,6,6,Ip Man,3,6,Donny Yen4 ,Filme,Gemini Man,2019/11/20 00:00:00,116,166623705.0,7,7,Henry Brogan,4,7,Will Smith2,Filme,O Rei Leão,2019/07/19 00:00:00,118, 1654791102.0,4,4,Simba,2,4,Donald Glover2,Filme,O Rei Leão,2019-07-19 00:00:00,118,1654791102.0,5,5,Nala,2,5,Beyoncé

Como podemos ver, as informações do filme se repetem. Esses dados repetidos podem levar ao que é conhecido comoexplosão cartesianase houver tabelas suficientes envolvidas em uma consulta.

EF Core introduziu umAsSplitQuerymétodo que permite que o Entity Framework divida cada entidade relacionada em uma consulta em cada tabela.

var filmes = banco de dados .Movies .AsSplitQuery() .Include(m => m.Characters) .ThenInclude(c => c.Actor) .OrderByDescending(x => x.WorldwideBoxOfficeGross);

Ao adicionar oAsSplitQuerymétodo, agora temos três instruções SQL paraFilmes,Personagens, eAtor. Observando a string de consulta de diagnóstico do EF Core, vemos o seguinte SQL.

SELECT "p".."Id", "p".."Discriminador", "p".."Nome", "p".."Release", "p".."DuraçãoEmMinutos", "p".."WorldwideBoxOfficeGross"FROM " Productions" AS "p"WHERE "p".."Discriminador" = 'Filme'ORDER BY "p".."WorldwideBoxOfficeGross" DESC, "p".."Id"

Esta consulta LINQ está sendo executada no modo de consulta dividida. O SQL mostrado é para a primeira consulta a ser executada. Consultas adicionais também podem ser executadas dependendo dos resultados da primeira consulta.

Vale a pena experimentarAsSplitQuery, pois pode acelerar as consultas e reduzir o tráfego de rede ao remover a duplicação de dados.

Constantes em expressões

O EF Core otimiza as consultas armazenando em cache as expressões LINQ, mas primeiro ele precisa compilar nossas expressões LINQ. Esse processamento de expressões LINQ é perceptível em ambientes de produção. Veja o exemplo a seguir.

var first = database.Movies.First(m => m.Id == 1);var second = database.Movies.First(m => m.Id == 2);

Essas duas consultas parecem idênticas, mas são compiladas em duas entradas de cache separadas quando o identificador é uma constante. Podemos otimizar essas consultas para compartilhar a mesma forma com modificações aparentemente menores.

var id = 1;var first = database.Movies.First(m => m.Id == id);id = 2;var second = database.Movies.First(m => m.Id == id);

Agora obtemos os mesmos resultados e armazenamos em cache a mesma consulta em duas instâncias separadas de seu uso. Usando constantes em nossas consultas, podemos inadvertidamente poluir o cache de consulta interno do EF Core e prejudicar o desempenho geral da consulta.

Injeção de SQL por acidente

A interpolação de strings é um dos melhores recursos do C# da última década. É uma conveniência que economizou incontáveis ​​horas de cada desenvolvedor C# embaralhando valores de índice em strings de formato. O EF Core permite o uso de interpolação de cadeia de caracteres ao usar SQL bruto. Ainda assim, os desenvolvedores devem ter cuidado para não refatorar seu código em um estado vulnerável à injeção de SQL inadvertidamente. Vamos começar com um SQL parametrizado usando uma string interpolada.

var id = 1;var results = database .Movies .FromSqlInterpolated($"Selecione * From Movies where id = {id}") .ToQueryString();

Quando olhamos para o SQL de nossa consulta, vemos que o EF Core parametrizou oeu ia.

.param set p0 1SELECT "p".."Id", "p".."Discriminador", "p".."Nome", "p".."Release", "p".."DuraçãoEmMinutos", "p"." WorldwideBoxOfficeGross"FROM ( Select * From Movies where id = @p0) AS "p"WHERE "p"."Discriminator" = 'Movie'

Podemos querer mover nossa consulta para outra variável para umlimpadorprocurando instrução LINQ.

var id = 1;var query = $"Selecione * Dos filmes where id = {id}";var results = banco de dados .Movies .FromSqlRaw(query) .ToQueryString();

Vamos ver qual é a instrução SQL resultante após nossa refatoração.

SELECT "p".."Id", "p".."Discriminador", "p".."Nome", "p".."Release", "p".."DuraçãoEmMinutos", "p".."WorldwideBoxOfficeGross"FROM ( Selecione * From Movies where id = 1) AS "p"WHERE "p".."Discriminator" = 'Filme'

Caramba! Acabamos de introduzir uma possível injeção de SQL. O EF Core não está mais parametrizando nossoeu iavariável. O risco se torna mais perigoso se aceitarmos a entrada do usuário na forma de um parâmetro de string.

A abstração do EF Core protege os desenvolvedores da introdução de ataques de injeção de SQL. Ainda assim, ao usar as interfaces SQL, os desenvolvedores correm um risco maior de perfurar a proteção fornecida pelo uso de instruções LINQ.

Atualizações Ineficientes

Dada a interface LINQ do EF Core, é tentador fazer todas as nossas operações usando nossas entidades C#. Ao lidar com grandes operações de conjunto de dados, é melhor adotar o mecanismo de armazenamento de dados subjacente em vez do LINQ em milhares de registros.

var filmes = banco de dados .Movies .OrderByDescending(x => x.WorldwideBoxOfficeGross);foreach (var filme em filmes){ filme.DurationInMinutes += 10; // trailers}database.SaveChanges();

Em vez disso, poderíamos usar uma única consulta SQL.

database.Database .ExecuteSqlRaw( "UPDATE [Productions] " + "SET [DurationInMinutes] = [DurationInMinutes] + 10 " + "WHERE Discriminator = 'Movie';");

Alcançamos o mesmo resultado sem o custo de conversas na rede.

Resiliência de conexão

Ao desenvolver em bancos de dados locais, às vezes podemos considerar a estabilidade de nossas conexões garantida. A produção é um pouco menos confiável quando se trata de confiabilidade de conexão.

O EF Core possui mecanismos de resiliência de conexão integrados que dão suporte a estratégias de repetição e resfriamento. Eles são ativados por padrão ao usar mecanismos de banco de dados variantes do SQL Server, mas podemos configurar a resiliência para nossas necessidades específicas.

substituição protegida void OnConfiguring(DbContextOptionsBuilder optionsBuilder){ optionsBuilder .UseSqlServer( "", options => options.EnableRetryOnFailure( maxRetryCount: 4, maxRetryDelay: TimeSpan.FromSeconds(1), errorNumbersToAdd: new int[] { } )) ;}

É importante entender que as conexões com bancos de dados não são garantidas como estáveis. Usando um software de monitoramento, notamos que há discrepâncias estranhas no desempenho, provavelmente devido à estratégia de execução que compensa uma falha na conexão ou o tempo limite do SQL. Às vezes, podemos corrigir esses problemas por meio do gerenciamento de infraestrutura ou otimizando as consultas para sobrecarregar menos nosso banco de dados.

Conclusão

O EF Core melhorou muitos problemas encontrados em versões anteriores do Entity Framework. Embora ainda seja uma abstração para mecanismos de banco de dados, as adições de interface ao EF Core parecem abraçar a inevitabilidade de lidar com o banco de dados.

Os aprimoramentos incluem combinar, dividir e executar SQL de maneiras anteriormente complicadas. O EF Core também oferece mais opções de extensibilidade aos desenvolvedores para lidar com problemas de acesso a dados, como filtragem de consultas, divisão de tabelas e herança. Os benefícios adicionais de uma melhor depuração no EF Core tornam a biblioteca mais fácil de recomendar aos desenvolvedores. O EF Core é menos uma caixa preta do que as versões anteriores, ajudando os desenvolvedores a diagnosticar problemas mais rapidamente.

Como palavra final, os novos aprimoramentos do EF Core abrangem o banco de dados e o SQL mais do que nunca, e é por isso que é importante aprendermos tudo o que pudermos sobre o banco de dados que escolhemos. Compreender o funcionamento interno de um mecanismo de banco de dados e a sintaxe SQL específica dará aos desenvolvedores a vantagem mais significativa, pois os desenvolvedores podem usar esse conhecimento para otimizar qualquer limitação do EF Core.

Obrigado por ler e, por favor, deixe quaisquer comentários e perguntas abaixo. _