API Setup: DI, SQLite, Swagger In .NET Program.cs

Nov 18, 2025 by Admin 50 views

E aí, pessoal! Se você está construindo uma API robusta e moderna em .NET 10, sabe que o arquivo Program.cs é o verdadeiro coração da sua aplicação. É ali que toda a mágica acontece, onde configuramos os serviços, conectamos o banco de dados e habilitamos ferramentas essenciais para desenvolvimento e documentação. Neste artigo, vamos desmistificar a configuração do Program.cs para o seu projeto CatalogoDeMidia.Api, focando em três pilares fundamentais: a Injeção de Dependência (DI), a integração com o banco de dados SQLite e a ativação do Swagger para uma documentação impecável e testes rápidos. Prepare-se para deixar sua API tinindo e pronta para decolar!

Um Program.cs bem configurado não é apenas uma questão de seguir receitas; é sobre entender como cada peça se encaixa para formar um sistema coeso, performático e fácil de manter. Especialmente em um contexto de arquitetura DDD (Domain-Driven Design), como o que temos no CatalogoDeMidia.sln, a forma como registramos nossos serviços e dependências é crucial. Vamos mergulhar nos detalhes para que você não só configure, mas também compreenda cada etapa desse processo vital. Ao final, você terá um CatalogoDeMidia.Api que não só funciona, mas que está estruturado para crescer e evoluir sem dores de cabeça, com DI, SQLite e Swagger configurados de forma elegante e eficiente. Bora começar a codificar com inteligência e estratégia!

Entendendo o Cenário: Seu `CatalogoDeMidia.Api` e a Arquitetura DDD

E aí, galera! Antes de botar a mão na massa e mergulhar fundo na configuração do Program.cs, é crucial que a gente entenda bem o terreno onde estamos pisando. O projeto CatalogoDeMidia.Api não é um bicho solto; ele faz parte de uma solution maior e segue princípios de arquitetura bem definidos. Seu CatalogoDeMidia.Api foi concebido como uma Web API em .NET 10, o que já nos dá uma pista sobre as tecnologias e a abordagem moderna que vamos usar. Estamos falando de um ambiente onde a performance e a escalabilidade são importantes, e o Program.cs é o ponto de entrada, o cérebro que orquestra tudo isso, desde a inicialização dos serviços até a configuração do pipeline de requisições. Pensa nele como o maestro da sua orquestra de código!

No nosso contexto, a solution CatalogoDeMidia.sln já existe e contém projetos distintos que seguem a filosofia do Domain-Driven Design (DDD). Isso significa que temos camadas bem definidas: CatalogoDeMidia.Dominio (o coração do seu negócio, com suas entidades e regras), CatalogoDeMidia.Aplicacao (onde ficam os casos de uso, orquestrando as operações do domínio), CatalogoDeMidia.Infraestrutura (responsável pelos detalhes técnicos, como persistência de dados e acesso a serviços externos), e CatalogoDeMidia.McpServer (que, por agora, podemos considerar para outros serviços). O CatalogoDeMidia.Api é a nossa camada de apresentação, a porta de entrada para o mundo externo interagir com todo esse ecossistema. Ele não deve ter regras de negócio complexas, mas sim expor os casos de uso definidos na camada de aplicação.

É fundamental que você, antes de qualquer alteração, dê uma boa lida na pasta instructions na raiz do repositório. Lá, você vai encontrar ouro em forma de documentação, especialmente nos arquivos 10-tecnologias-e-padroes.md, 20-arquitetura-ddd-e-dependencias.md e 40-estrutura-da-solution-e-detalhamento.md. Esses documentos não apenas detalham que estamos usando .NET 10 e C# 14 (sempre bom estar atualizado, né?), mas também definem a arquitetura DDD e, mais importante para o nosso papo de hoje, como a injeção de dependência deve ser organizada entre as camadas. Eles especificam que usaremos SQLite com Entity Framework Core e que teremos um CatalogoDeMidiaDbContext na camada de Infraestrutura. Fique ligado: essa leitura prévia te economiza horas de dor de cabeça e garante que você está construindo algo que se encaixa perfeitamente no design já estabelecido. O Program.cs é o lugar onde todas essas definições arquiteturais se encontram e ganham vida, então entendê-las de antemão é o seu superpoder.

Configurando o `Program.cs`: O Coração da Sua API .NET 10

Agora que já entendemos o palco, é hora de entrar em ação e configurar o Program.cs do CatalogoDeMidia.Api. Este arquivo é, sem dúvida, o ponto de partida para qualquer aplicação ASP.NET Core moderna, e no .NET 10 ele continua com uma sintaxe simplificada e poderosa. A primeira coisa que faremos é criar o builder da nossa aplicação. Esse builder é como um kit de ferramentas que nos permite registrar serviços (o famoso builder.Services) e acessar as configurações (através de builder.Configuration). É nesse ponto que começamos a dar forma à nossa API, definindo o que ela será capaz de fazer e como ela vai funcionar. Pensa no builder como o seu assistente pessoal que organiza tudo antes do show começar.

O Setup Inicial do Builder e Serviços Essenciais

Para começar, vamos utilizar o padrão de inicialização mais recente, que é super clean e eficiente. Basicamente, criamos uma instância de WebApplication.CreateBuilder(args) e, a partir dela, temos acesso a tudo que precisamos. Logo de cara, precisamos registrar os serviços básicos que toda Web API que se preze utiliza. Estamos falando de coisas como AddControllers(), se você for usar o padrão de Controllers, AddEndpointsApiExplorer() (que é essencial para o Swagger funcionar), e claro, AddSwaggerGen(), que habilita a geração da documentação da API. É aqui que começamos a dizer ao .NET o que nossa aplicação vai expor e como ela vai se descrever.

using Microsoft.AspNetCore.Builder;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
// Adicionar os usings para as extensões de Aplicação e Infraestrutura
// using CatalogoDeMidia.Aplicacao.Configuracao;
// using CatalogoDeMidia.Infraestrutura.Configuracao;

var builder = WebApplication.CreateBuilder(args);

// 1. Registro dos serviços da camada de apresentação
// Galera, aqui a gente registra os serviços básicos da nossa Web API.
// Se você está usando Controllers, 'AddControllers()' é o cara!
builder.Services.AddControllers();
// 'AddEndpointsApiExplorer()' é essencial para o Swagger descobrir seus endpoints.
builder.Services.AddEndpointsApiExplorer();
// 'AddSwaggerGen()' habilita a geração da documentação Open API (Swagger).
builder.Services.AddSwaggerGen();

// ... Próximos passos de configuração ...

Perceberam como é direto ao ponto? Com essas poucas linhas, já temos a estrutura básica para nossa API rodar e o Swagger pronto para ser ativado. É importante garantir que os namespaces estejam corretos e que você tenha as referências aos pacotes NuGet necessários, tipo Swashbuckle.AspNetCore. O .NET 10 torna essa parte inicial super fluida, permitindo que a gente se concentre no que realmente importa: a lógica de negócio e a experiência do usuário. Fica a dica: manter o Program.cs limpo e organizado é um baita diferencial, facilitando a manutenção futura e o onboarding de novos devs no projeto. A clareza aqui é ouro, pessoal!

Injeção de Dependência (DI): Conectando Suas Camadas de Aplicação e Infraestrutura

Chegamos a um dos momentos mais importantes na configuração do nosso Program.cs: a Injeção de Dependência (DI). Se você está seguindo a arquitetura DDD como no CatalogoDeMidia.Api, a DI é seu melhor amigo. Ela é a responsável por desacoplar suas camadas, permitindo que o CatalogoDeMidia.Api (camada de apresentação) use os serviços de CatalogoDeMidia.Aplicacao (casos de uso) e CatalogoDeMidia.Infraestrutura (acesso a dados e outros detalhes técnicos) sem precisar saber como eles são criados. Pensa na DI como um garçom super eficiente: você pede o prato (um serviço) e ele entrega, sem que você precise ir até a cozinha e prepará-lo. Isso torna seu código mais flexível, testável e manutenível – tudo que a gente ama em um projeto moderno!

No nosso projeto CatalogoDeMidia, a expectativa é que tenhamos classes de extensão dedicadas a registrar os serviços de cada camada no contêiner de DI. Isso é uma prática excelente para manter o Program.cs limpo e organizar a responsabilidade de registro. Por exemplo, poderíamos ter algo como CatalogoDeMidia.Aplicacao.ConfiguracaoAplicacaoExtensoes para a camada de aplicação e CatalogoDeMidia.Infraestrutura.ConfiguracaoInfraestruturaExtensoes para a infraestrutura. Essas classes encapsulam toda a lógica de registro, expondo métodos simples como AdicionarAplicacao() e AdicionarInfraestrutura() para serem chamados no Program.cs. Essa é a abordagem que vamos seguir para manter tudo organizado e escalável, conforme definido nas nossas instructions.

Registrando a Lógica de Negócio e o Acesso a Dados

Para registrar esses serviços, vamos chamar os métodos de extensão a partir de builder.Services. Um detalhe crucial é que a camada de Infraestrutura provavelmente precisará de uma connection string para configurar o acesso ao banco de dados SQLite. Essa connection string deve ser lida das configurações da aplicação, geralmente do appsettings.json, o que nos dá flexibilidade para trocar de banco de dados ou de ambiente sem recompilar o código. Vamos buscar essa string de uma seção específica, por exemplo, ConnectionStrings:CatalogoDeMidiaSqlite, garantindo que nosso acesso a dados seja configurável e robusto. A DI é um conceito poderoso, e configurá-la corretamente é um divisor de águas para a qualidade do seu software. Ela permite que a gente se concentre na lógica de negócio sem se preocupar com a complexidade de gerenciar as dependências manualmente. É o caminho para um código mais limpo e modular, essencial para a longevidade do seu CatalogoDeMidia.Api.

// ... (código anterior do builder)

// 2. Leitura da Connection String do SQLite
// Fica ligado, galera! A connection string para o nosso SQLite será lida do appsettings.json.
// É uma prática padrão para tornar a configuração mais flexível entre ambientes.
// Por exemplo, ConnectionStrings:CatalogoDeMidiaSqlite
var connectionString = builder.Configuration.GetConnectionString("CatalogoDeMidiaSqlite");

// Verificação básica para garantir que a connection string foi encontrada.
if (string.IsNullOrEmpty(connectionString))
{
    // Em um cenário real, você pode querer logar um erro ou lançar uma exceção mais específica.
    throw new InvalidOperationException("A connection string 'CatalogoDeMidiaSqlite' não foi encontrada nas configurações.");
}

// 3. Registro dos serviços de Aplicação e Infraestrutura na DI
// Aqui é onde a mágica da Injeção de Dependência acontece!
// Usamos métodos de extensão para registrar os serviços de cada camada.
// Isso mantém o Program.cs limpo e organiza a responsabilidade de registro.
// builder.Services.AdicionarAplicacao(); // Exemplo de como registrar os serviços de Aplicação
// builder.Services.AdicionarInfraestrutura(connectionString); // Exemplo de como registrar a Infraestrutura, passando a connection string

// Atenção: Os nomes dos métodos de extensão podem variar de acordo com a implementação
// nas camadas de Aplicacao e Infraestrutura. Consulte os arquivos 'instructions'!

// ... (continua no próximo passo)

SQLite: Seu Banco de Dados Local Simples e Eficaz

Agora, vamos falar de SQLite, a escolha perfeita para o banco de dados do nosso CatalogoDeMidia.Api em ambientes de desenvolvimento e testes. Por que SQLite, você pergunta? Simples! Ele é um banco de dados leve, autocontido e sem servidor, o que significa que ele opera a partir de um único arquivo no disco. Isso o torna incrivelmente fácil de configurar e usar, sem a necessidade de instalar e gerenciar um servidor de banco de dados separado. Para protótipos, testes unitários ou até mesmo pequenas aplicações, o SQLite é um campeão da praticidade. No contexto do Entity Framework Core, a integração é super fluida, e nossa camada de CatalogoDeMidia.Infraestrutura será a responsável por orquestrar essa comunicação, mas o Program.cs tem um papel vital ao fornecer a chave para essa conexão: a connection string.

Nossa connection string para o SQLite é o que diz ao Entity Framework Core onde encontrar o arquivo .db do banco de dados. Como mencionado anteriormente, essa string será lida do appsettings.json, garantindo que a localização do seu banco possa ser facilmente alterada sem precisar recompilar sua aplicação. Isso é uma vantagem enorme para o desenvolvimento, pois permite que cada desenvolvedor tenha sua própria instância local do banco de dados sem conflitos. A flexibilidade que a configuração via appsettings.json oferece é um divisor de águas, especialmente em equipes grandes ou ambientes de CI/CD, onde a automação é rei. A camada de CatalogoDeMidia.Infraestrutura contém o nosso CatalogoDeMidiaDbContext, que será configurado para usar o provedor SQLite do Entity Framework Core, utilizando a connection string que fornecemos aqui.

Configurando a Connection String e o Acesso ao SQLite

Um exemplo comum de connection string para SQLite é Data Source=Data/catalogo_de_midia.db;. Isso significa que o arquivo do banco de dados (catalogo_de_midia.db) será criado dentro de uma pasta Data na raiz do seu projeto CatalogoDeMidia.Api. É uma localização conveniente para o desenvolvimento, pois mantém o arquivo do banco de dados junto com o código-fonte (mas lembre-se de configurar seu .gitignore para não versionar arquivos .db em ambientes de produção, claro!). O Program.cs simplesmente faz a ponte: ele pega a informação de onde o banco está e a repassa para a camada de Infraestrutura através do método de extensão. Isso mantém a responsabilidade de cada camada bem definida, um princípio chave do DDD. Ao garantir que o Program.cs lide bem com essa configuração, estamos preparando o terreno para que a persistência de dados do seu CatalogoDeMidia.Api funcione de forma consistente e confiável, desde o primeiro dotnet run.

// Exemplo de como sua section de ConnectionStrings ficaria no appsettings.json
{
  "ConnectionStrings": {
    "CatalogoDeMidiaSqlite": "Data Source=Data/catalogo_de_midia.db;"
  },
  // ... outras configurações ...
}

// ... (código anterior da Injeção de Dependência)

// Comentário em Português do Brasil:
// A connection string 'Data Source=Data/catalogo_de_midia.db;' indica que o
// arquivo do banco de dados SQLite ('catalogo_de_midia.db') será armazenado
// na pasta 'Data' localizada na raiz do projeto 'CatalogoDeMidia.Api'.
// Essa localização é ideal para desenvolvimento e testes locais, mantendo
// o banco de dados próximo ao código-fonte da aplicação.

// ... (continua no próximo passo)

Swagger: Documentação e Teste de API na Ponta dos Dedos

Beleza, galera! Depois de configurar a DI e o acesso ao SQLite, é hora de trazer uma ferramenta que vai ser sua melhor amiga no desenvolvimento e consumo da sua API: o Swagger. O Swagger (ou Open API Specification, como é formalmente conhecido) não é apenas uma ferramenta de documentação; ele é um playground interativo para sua API. Com ele, você consegue ver todos os seus endpoints, entender os parâmetros de entrada e saída, e até mesmo testar suas requisições diretamente do navegador, sem precisar de ferramentas como Postman ou Insomnia. Isso não só acelera o desenvolvimento, como também facilita muito a vida de quem vai consumir sua API, seja outro desenvolvedor da sua equipe ou um parceiro externo. Ter o Swagger habilitado é um selo de qualidade para qualquer API moderna.

Para habilitar o Swagger no seu CatalogoDeMidia.Api, precisamos configurar alguns middlewares no pipeline HTTP da aplicação. Primeiramente, no ambiente de desenvolvimento, é altamente recomendado usar app.UseSwagger() e app.UseSwaggerUI(). O UseSwagger() é o responsável por gerar o arquivo de especificação JSON da sua API, enquanto o UseSwaggerUI() é quem renderiza aquela interface gráfica bonita e interativa que todo mundo conhece e adora. Essa distinção permite que, em ambientes de produção, você possa servir a especificação JSON sem a UI, caso precise de uma abordagem mais controlada ou personalizada. A gente sempre prioriza a experiência do desenvolvedor, e o Swagger é um dos maiores facilitadores nesse sentido. Ele transforma a tarefa de documentar e testar uma API em algo prazeroso e eficiente.

Habilitando o Swagger e Montando o Pipeline da Aplicação

Além do Swagger, o pipeline HTTP precisa de alguns outros middlewares padrão para que a API funcione corretamente. Estamos falando de UseHttpsRedirection() (se você quiser garantir que todas as requisições sejam feitas via HTTPS, o que é uma boa prática de segurança!), e UseAuthorization() (mesmo que você ainda não tenha autenticação e autorização implementadas, é bom deixar o gancho preparado para o futuro). E, claro, a peça final para que seus controllers sejam alcançados: app.MapControllers(). Essa linha é a responsável por mapear as rotas dos seus controllers para as requisições HTTP recebidas. Com esses middlewares em ordem, sua API estará não só documentada, mas também segura e pronta para responder às requisições do mundo real. Lembre-se que a ordem dos middlewares no pipeline é importante, pois eles são executados sequencialmente. Um Program.cs bem estruturado não só faz a aplicação rodar, mas também prevê futuras necessidades e garante que o projeto siga os melhores padrões de desenvolvimento. Bora lá com o código!

// ... (código anterior da Injeção de Dependência)

var app = builder.Build();

// 4. Configuração do Pipeline HTTP
// Galera, aqui configuramos como as requisições HTTP serão processadas.

// Em ambiente de desenvolvimento, a gente adora o Swagger pra testar e documentar a API!
if (app.Environment.IsDevelopment())
{
    // 'UseSwagger()' gera o arquivo JSON de especificação OpenAPI.
    app.UseSwagger();
    // 'UseSwaggerUI()' renderiza a interface gráfica interativa do Swagger.
    app.UseSwaggerUI();
}

// 'UseHttpsRedirection()' redireciona automaticamente requisições HTTP para HTTPS.
// Isso é uma boa prática de segurança, mesmo que ainda não tenhamos certificado em dev.
app.UseHttpsRedirection();

// 'UseAuthorization()' é um placeholder para futura configuração de autenticação/autorização.
// Mesmo que não haja lógica implementada agora, é bom deixar no pipeline.
app.UseAuthorization();

// 'MapControllers()' mapeia os endpoints dos seus controllers.
// Essencial para que as requisições cheguem aos métodos corretos!
app.MapControllers();

// Comentário em Português do Brasil:
// Aqui, no futuro, poderíamos adicionar outras configurações importantes como
// políticas de CORS (Cross-Origin Resource Sharing), middlewares de tratamento
// de erro personalizados, autenticação JWT, etc.
// A organização do pipeline é crucial para o comportamento da API.

app.Run();

Conclusão: Sua API .NET 10 Pronta para Decolar!

Parabéns, galera! Chegamos ao fim da nossa jornada de configuração do Program.cs do CatalogoDeMidia.Api. Vocês acabaram de transformar um arquivo "casca" em um coração pulsante e bem orquestrado para sua API .NET 10. Recapitulando, configuramos a Injeção de Dependência (DI) para conectar suas camadas de Aplicação e Infraestrutura de forma elegante e desacoplada, preparamos o terreno para o SQLite como seu banco de dados local simples e eficaz, e habilitamos o Swagger para uma documentação interativa e testes descomplicados.

Agora, ao rodar dotnet run no seu projeto CatalogoDeMidia.Api, você verá que a aplicação compila e inicia sem erros, e mais importante, você poderá acessar o Swagger no navegador (geralmente em /swagger ou /swagger/index.html) e ver seus endpoints prontos para serem testados. Mesmo que seus controllers ainda estejam vazios, a estrutura fundamental está montada! Vocês têm em mãos uma base sólida e moderna para continuar desenvolvendo os casos de uso do CatalogoDeMidia, sabendo que a arquitetura está bem definida e as ferramentas essenciais estão no lugar. Continuem explorando, codificando e construindo coisas incríveis. A jornada de desenvolvimento é contínua, e cada passo como este nos deixa mais próximos de uma solução robusta e de alta qualidade. Até a próxima!