As decisões de um projeto back-end real com .NET 10 e SQLite

Neste evento da comunidade, Tiago Aguiar recebeu Clarissa Cássia, que apresentou pela primeira vez ao vivo um projeto de estudo em .NET 10: uma Minimal API de catálogo de livros que usa Dapper e SQLite. Thais Cavalcante, convidada do evento anterior, voltou para comentar. A pergunta que guiou a conversa foi a mesma de sempre: por que cada decisão foi tomada e o que mudaria se o projeto crescesse.

O que foi discutido

• A proposta do projeto: um CRUD de livros com Minimal API, Dapper e SQLite, pensado para que qualquer pessoa clone e rode sem instalar um banco
• Minimal API versus controllers: menos cerimônia, endpoints mapeados direto por verbo HTTP e o motivo de extrair os endpoints para uma classe separada em vez de deixar tudo no Program.cs
• Dapper versus Entity Framework: controle sobre o SQL de um lado, migrations e produtividade do outro, e o uso combinado dos dois em projetos reais
• A criação da tabela na inicialização da aplicação, feita por uma query manual porque o Dapper não traz migrations
• O padrão Repository sobre um micro-ORM e como a injeção da interface facilita os testes unitários
• DTO versus Model: o objeto de entrada sem Id, o Book devolvido direto ao cliente e por que isso pode mudar com um BookResponse
• SELECT * versus colunas nomeadas, com o impacto de custo e de volume de dados
• O uso de IA para gerar código: quem conduz a organização do projeto é a pessoa desenvolvedora
• Próximos passos: paginação, usuários, validação de entrada, tratamento de erros, testes e uma camada de infraestrutura em projeto separado

Sobre Clarissa Cássia

Clarissa atuou por muito tempo na área da saúde e iniciou a transição para tecnologia entre 2022 e 2023. Fez várias trilhas de estudo desde a lógica de programação, trabalhou por pouco mais de um ano como desenvolvedora em um software de gestão educacional e ali teve o primeiro contato com ORM e Entity Framework, aprendendo no dia a dia. Tem o hábito de transformar tudo que estuda em um projeto pequeno no GitHub, e o catálogo com Dapper nasceu assim, como forma de testar o que aprendeu no curso.

Principais pontos

Estudar construindo projetos pequenos

Clarissa conta que, para cada tecnologia que estuda, cria um projeto, mesmo simples e sem intenção de ir para produção. Tiago reforçou que o exercício de curso é um contexto controlado e que o passo natural seguinte é um projeto próprio, sem a pressão de construir o "mega projeto" com cache, autenticação e milhões de requisições. O projeto do evento é justamente isso: pequeno de propósito, com o objetivo de entender uma ferramenta específica.

"tudo que eu estudo, que eu acho legal, eu tenho que fazer um projeto, mesmo que simples, mesmo que nem você falou que não seja uma coisa complexa, que não vá rodar em produção, mas eu acho que eu consigo aprender melhor e colocando em prática os conceitos do que ficar só ali nos exercícios de um curso" por Clarissa Cássia

Minimal API e organização dos endpoints

Os endpoints do projeto são mapeados direto em rotas, um por verbo HTTP (GET, POST, PUT e DELETE), sem classes de controller. No Program.cs ficam apenas as configurações, como CORS, Swagger e a inicialização do banco, e os endpoints de livros foram para uma classe separada por meio de um método de extensão. A ideia é que novos grupos de endpoints, como usuários e autores, ganhem a mesma pasta. Tiago comentou que, na era da IA, código gerado sem direcionamento tende a crescer torto, e que cabe a quem programa decidir a organização. Pelo chat, um participante contou que o PicPay usa Minimal APIs na área de investimentos.

"a maneira que eu quis me organizar foi desse jeito, separando as coisas" por Clarissa Cássia

Dapper ou Entity Framework: depende da proposta

Clarissa começou o Dapper para entender a base antes de avançar no Entity Framework, que abstrai muito e entrega mais recursos, como migrations. O Dapper dá controle total sobre a query, mas exige criar à mão o que o EF gera sozinho, como a tabela no início da aplicação. Tiago acrescentou que é comum usar os dois no mesmo projeto, por exemplo Dapper para leitura e EF para escrita, ou o EF apenas para gerenciar migrations. Comentários do chat reforçaram que escrever SQL à mão ajuda quem está aprendendo e que há equipes que padronizam o Dapper para otimizar consultas.

"hoje eu vejo que os dois são bons pra propostas, depende da proposta" por Clarissa Cássia

Repository e a vantagem para os testes

Clarissa separou a camada de acesso a dados em repositórios para não misturar responsabilidades: os endpoints chamam o repositório, e é nele que o Dapper executa o SQL. Tiago destacou outra vantagem, ligada a testes: como o endpoint recebe a interface e não a classe concreta, é possível substituir o acesso ao banco em testes unitários, deixando o banco real para os testes de integração. Thais contou que fez seus primeiros testes com xUnit no projeto do evento anterior, aprendendo na prática, e Clarissa disse que testes e tratamento de erros ficaram de fora desta primeira versão.

"então acredito que dessa maneira a gente separando as classes separando os arquivos fica muito mais organizado" por Clarissa Cássia

DTO e consulta: devolver e buscar só o necessário

O BookRequestDTO recebe título, autor e ano, sem o Id, que o banco gera. Hoje o Book completo é devolvido ao cliente, e Clarissa pretende criar um BookResponse para enxugar o que sai da API. Thais citou o uso de DTO para não expor dados sensíveis, e Tiago ligou o tema ao tamanho do pacote trafegado em redes móveis. No mesmo bloco, Clarissa admitiu que um dos métodos usa SELECT * por inconsistência, e Tiago explicou por que nomear as colunas evita trazer dados desnecessários e poupa o banco de descobrir os campos a cada consulta.

"eu vou ser bem sincera com você que usar o asterisco aqui foi uma inconsistência mesmo minha" por Clarissa Cássia

Frase de destaque

"essa troca independente de nível independente de senioridade eu acho que é bem interessante, bem válido" por Clarissa Cássia

Lições do evento

1. Um projeto pequeno e focado em uma tecnologia ensina mais do que o exercício guiado de um curso.
2. Minimal API reduz a cerimônia, mas separar endpoints e configuração em arquivos próprios mantém o projeto organizado quando ele cresce.
3. Dapper e Entity Framework não competem de verdade: a escolha depende do contexto, e os dois podem conviver no mesmo projeto.
4. Injetar a interface do repositório, e não a classe concreta, é o que torna o código testável sem depender do banco.
5. Nomear as colunas no SELECT e separar DTO de entrada e saída são hábitos baratos que evitam problemas de volume e exposição de dados.
6. O próximo passo natural de um projeto em crescimento é mover o acesso a dados para uma camada de infraestrutura em um projeto separado.