A diferença entre ExecuteSqlRaw é clara, mas ExecuteSqlInterpolated e ExecuteSql parecem semelhantes, também nos documentos.
Ambos têm os mesmos parâmetros e saída:
public static int ExecuteSqlInterpolated (this Microsoft.EntityFrameworkCore.Infrastructure.DatabaseFacade databaseFacade, FormattableString sql); public static int ExecuteSql (this Microsoft.EntityFrameworkCore.Infrastructure.DatabaseFacade databaseFacade, FormattableString sql);
Ambos têm a mesma descrição: "Executa o SQL fornecido no banco de dados e retorna o número de linhas afetadas."
Nenhum deles está marcado como obsoleto
A única diferença nos documentos:
Portanto, ExecuteSql é introduzido no EF Core 7.
Então, são iguais e devo usar ExecuteSql em vez de ExecuteSqlInterpolated para EF Core 7/8, pois este é mais recente?
Usar
ExecuteSql
.Esses dois existem por razões históricas e psicológicas humanas, para evitar que as pessoas causem problemas de injeção de SQL, mesmo que a EF torne trivial escrever consultas seguras porque elas estavam com preguiça de digitar
Interpolated
em vez deRaw
ler os documentos. Tenho certeza de que as questões relevantes do GH não usam essa linguagem.Conforme explicam os documentos de consultas SQL :
O mesmo vale para
ExecuteSql
.EF Core 2.x: Somente FromSQL
O EF Core sempre permitiu a execução de consultas com parâmetros passados como valores extras, por exemplo, no EF Core 2.0 você poderia escrever:
Diferentes sobrecargas do mesmo método aceitariam uma string interpolada cujas variáveis fossem convertidas em parâmetros:
Isso é necessário porque as pessoas sempre tentarão usar strings interpoladas para construir consultas. Ao tornar o método accept
FormattableString
, a consulta anteriormente insegura pode ser convertida em uma consulta segura.Isso causou confusão, pois a interpolação de strings nem sempre funcionava conforme o esperado . Em alguns casos ocorreu interpolação em vez de parametrização porque o compilador C# decidiu executar a interpolação:
Em outros casos, consultas parametrizadas EF que não deveriam ser parametrizadas :
Também era possível introduzir injeção de SQL involuntariamente, se você extraísse uma consulta longa para uma variável. O que você pensava que ainda era FormattableString agora era uma string normal. Eu posso ou não ter feito isso acidentalmente também:
EF Core 3: dois métodos separados
No EF Core 3.0 foram criados dois métodos separados, FromSqlInterpolated e FromSqlRaw . E adivinhe o que algumas pessoas fizeram... começaram a usar
FromSqlRaw
com strings interpoladas.Então, alguns desenvolvedores preguiçosos começaram a copiar tudo o que encontraram no primeiro resultado do Google, causando a proliferação de injeção de SQL na única plataforma que torna trivial evitá-la.
EF Core 7: Alias FromSqlInterpolado como FromSql
Desde o EF Core 7, o FromSql reintroduzido aceita apenas um FormattableString. Ele também tem 3 letras a menos para digitar e aparece acima
FromSqlRaw
no Intellisense.A questão relevante do GH diz:
Atualizar
Comecei a analisar problemas de GH contendo FromSqlInterpolated e vejo que ainda há confusão . Naquela edição, alguém estava tentando formatar o parâmetro de data:
Formatação como essa não faz sentido no SQL e, portanto, não é suportada.