LINQ e EF Core - Aula Prática

Exemplo 1 — A primeira consulta

Substitua todo o conteúdo do Program.cs por:

using Microsoft.EntityFrameworkCore;

using var db = new AppDbContext();

List<Funcionario> funcionarios = db.Funcionarios.ToList();

Console.WriteLine($"Total de funcionários: {funcionarios.Count}");
foreach (Funcionario f in funcionarios)
{
    Console.WriteLine($"{f.Id,3} | {f.Nome,-20} | {f.Cargo,-14} | {f.Salario,10:N2} | {(f.Ativo ? "Ativo" : "Inativo")}");
}

Rode com dotnet run. Você não escreveu nenhuma linha de SQL, nem leu nenhuma coluna "na mão": o EF Core montou o SELECT, executou no SQL Server e transformou cada linha do resultado em um objeto Funcionario — isso é a materialização.

Desafios:

• Descomente a linha do LogTo no AppDbContext.cs e rode de novo. Encontre no console o SELECT que o EF Core gerou. Ele é parecido com o que você escreveria?
• Na classe Funcionario, adicione uma propriedade que não existe no banco, por exemplo public string Email { get; set; } = string.Empty;, e rode. Leia a mensagem de erro. O que ela diz sobre o mapeamento? Depois, remova a propriedade.
• Agora remova temporariamente a propriedade Cargo da classe (e do Console.WriteLine) e rode. Dá erro? Olhe o SELECT gerado: a coluna Cargo ainda é consultada? Depois, volte a propriedade.

Pense e responda:

• Com base nos dois últimos desafios: quem "manda" no mapeamento — a tabela no banco ou a classe no C#? O que acontece quando os dois lados não batem?

Exemplo 2 — LINQ vira SQL

Agora a consulta que vimos na teoria. Com LINQ escrevemos a consulta em C#; o EF Core interpreta essa expressão e a transforma em SQL. O método ToQueryString() mostra esse SQL sem executar a consulta. Substitua o Program.cs por:

using Microsoft.EntityFrameworkCore;

using var db = new AppDbContext();

var consulta = db.Funcionarios
    .Where(f => f.Salario > 5000)
    .Select(f => new
    {
        f.Nome,
        f.Salario
    });

Console.WriteLine("SQL gerado pelo EF Core:");
Console.WriteLine(consulta.ToQueryString());
Console.WriteLine();

var funcionarios = consulta.ToList(); // só aqui a consulta vai de fato ao banco

foreach (var f in funcionarios)
{
    Console.WriteLine($"{f.Nome,-20} {f.Salario,10:N2}");
}

Desafios (para cada um, observe como o SQL gerado muda):

• Acrescente mais uma condição: apenas funcionários com salário acima de 5000 e ativos (&& f.Ativo).
• Ordene o resultado do maior para o menor salário com .OrderByDescending(f => f.Salario). Faz diferença colocar antes ou depois do Select?
• Inclua o Cargo no Select.
• Troque o .ToList() por .Count() (sem o Select) para descobrir quantos funcionários ganham mais de 5000. Qual SQL você imagina que é gerado? Confira com o LogTo.
• Use .Take(3) para trazer só os 3 maiores salários.

Pense e responda:

• Repare que ToQueryString() foi chamado antes do ToList() e mesmo assim já existia um SQL completo. O que isso indica sobre quando a consulta é realmente executada no banco?
• No SQL gerado, o WHERE aparece. Isso significa que o filtro é feito no banco ou no C#? Por que isso importa quando a tabela tem milhões de linhas?

Exemplo 3 — Inserindo com Add e SaveChanges

O DbContext também controla as alterações. O fluxo é: Add() → EF Core registra a alteração → SaveChanges() → EF Core gera SQL → SQL Server. Deixe o LogTo ligado e troque SEU NOME pelo seu nome de verdade:

using Microsoft.EntityFrameworkCore;

using var db = new AppDbContext();

var funcionario = new Funcionario
{
    Nome = "SEU NOME",
    Cargo = "Estagiário",
    Salario = 2000,
    Ativo = true
};

Console.WriteLine($"Id ANTES do SaveChanges: {funcionario.Id}");

db.Funcionarios.Add(funcionario);
Console.WriteLine("Add() chamado. Algum SQL apareceu no console até aqui?");

db.SaveChanges();

Console.WriteLine($"Id DEPOIS do SaveChanges: {funcionario.Id}");

Desafios:

• Rode e observe o log: o INSERT aparece depois do Add() ou só depois do SaveChanges()?
• Anote o Id impresso depois do SaveChanges() — você vai precisar dele no próximo exemplo. Quem gerou esse número: o C# ou o banco?
• Insira mais dois registros seus, desta vez chamando Add duas vezes e SaveChanges uma única vez no final. Quantos comandos foram enviados ao banco?
• Volte ao Exemplo 1 e confira que seus registros aparecem na listagem — junto com os dos colegas.

Exemplo 4 — Alterando e removendo

Para alterar, basta buscar o objeto, mudar a propriedade e chamar SaveChanges(). Não existe um método "Update" nesse fluxo: o DbContext percebe sozinho o que mudou. Troque ID_DO_SEU_REGISTRO pelo Id que você anotou no Exemplo 3:

using Microsoft.EntityFrameworkCore;

using var db = new AppDbContext();

int meuId = ID_DO_SEU_REGISTRO;

Funcionario? funcionario = db.Funcionarios.Find(meuId);

if (funcionario is null)
{
    Console.WriteLine("Registro não encontrado.");
    return;
}

Console.WriteLine($"Antes: {funcionario.Nome} - {funcionario.Salario:N2}");

funcionario.Salario = 6000;
db.SaveChanges();

Console.WriteLine($"Depois: {funcionario.Nome} - {funcionario.Salario:N2}");

E para remover um registro seu:

using Microsoft.EntityFrameworkCore;

using var db = new AppDbContext();

int meuId = ID_DO_SEU_REGISTRO;

Funcionario? funcionario = db.Funcionarios.Find(meuId);

if (funcionario is not null)
{
    db.Funcionarios.Remove(funcionario);
    db.SaveChanges();
    Console.WriteLine("Registro removido.");
}

Desafios:

• Com o LogTo ligado, observe o UPDATE gerado. Ele atualiza todas as colunas ou só o Salario?
• Rode o código de alteração duas vezes seguidas com o mesmo valor (6000). Na segunda vez, algum UPDATE é enviado? Por quê?

Pense e responda:

• Se o DbContext não recebe nenhum aviso de que Salario mudou, como ele descobre o que precisa ir no UPDATE? (Guarde essa pergunta — voltaremos a ela na próxima aula teórica.)